In late 2004, Ted Neward famously called Object-Relational-Mapping (ORM) the Vietnam of Computer Science. Recently I switched to .NET 4.5, hoping to reap the benefits of LINQ-to-Entities‘ support for the spatial datatypes. For SQL Server, this works every bit as well as the Entity Framework does in the first place – great for some databases, a hassle for others (particularly legacy databases).
When LINQ-to-SQL first came out – things didn’t really work too well for spatial. Back then, it took a little modification of the generated SQL queries before things could get rolling using WKT. Few people manage their spatial objects as WKT, of course, so you sprinkled some conversion code into your DAL. Nothing worked out of the box, but the solutions were clear and made sense.
With the Entity Framework’s new spatial support in the System.Data.Spatial namespace, did things improve? They certainly did if you’re just shuffling geometries from the web to SQL Server. But what about people who do real work? Their applications were all built using geometries from Vertesaur, DotSpatial, SharpMap, or NTS. So we’re still looking at conversion, mostly likely via WKT. Beyond that letdown, how is the database support? I personally ran into a lack of naive DbGeometry support when using SQLite. I wouldn’t have much cared if it were serialized to WKB or WKT, as long as something worked out of the box.
The plain truth is, its often easier to do things yourself than to learn the weird things other people do. So despite some great use cases, the new geospatial support in .NET 4.5, for me, is the wrong sized glass. This GIS-specific realization mirrors ORM’s issues in general. Synapses firing, my brain dug up an old Sam Saffron / Marc Gravell project called Dapper. Dapper has been called a “micro-ORM”; less of a ground assault and more of a smart bomb – you still manage your ADO connections and write your own SQL, it does fast binding of objects to query parameters and results.
In the end, I moved to Dapper. Its code-base was small enough for me to grok and hack geospatial support into in a few hours. Writing SQL is a fair trade for control, particularly when you need control – geospatial data storage being a prime candidate. It is great to generate object models using the Entity Framework; but I’ve grabbed my POCOs and switched to a smaller, easier to modify ORM with a more stable codebase.