Entity Framework 5 and Spatial Data (Part 2 - Comparison with NHibernate Spatial)

Part 1 - Introduction
Part 2 - Comparison with NHibernate Spatial

As promised in my previous post I'm going to do a comparison between NHibernate Spatial and Entity Framework.
 
I'll start by making a pros/cons list for both libraries, but just focusing on items that may differ between them.

 NHibernate Spatial

Pros:

• True abstraction from the database with IGeoAPI/NetTopologySuite
• Works with .NET 3.5 and newer

Cons:

• No longer actively developed
• Querying with LINQ/QueryOver doesn't work in many cases
• Some spatial operators are not implemented

Entity Framework 5 Beta 2 Spatial

Pros:

• Setup is a breeze
• Querying with LINQ works flawlessly.
• Natively integrated with Entity Framework

Cons:

• The DbGeography/DbGeometry types belong to System.Data.Spatial. Therefore, we're always tied to the database model, even if just conceptually.
• Requires .NET 4.5 (at least in the Beta 2. I don't know if support for 4.0 is on the road)

Now, allow me to dissect these points:

Spatial Abstraction

Regarding the abstraction, the folks that developed NHibernate Spatial decided to use IGeoAPI. It defines a bunch of interfaces in an attempt of standardizing the spatial types and operations. They're even agnostic to the fact that a database exists. For example, in NHibernate our POCO could be declared like:

public class Country
{
    public virtual IPoint Location { get; set; }
    public virtual IPolygon Area { get; set; }
}

NHibernate Spatial uses a library called NetTopologySuite to implement these interfaces. Then, even if no database is involved, we have access to a full-set of spatial operations in our C# code.

With Entity Framework this is not the case. The same class would be declared as:

public class Country
{
    public DbGeography Location { get; set; }
    public DbGeography Area { get; set; }
}

The DbGeography class belongs to the System.Data.Spatial namespace. We're tied to a Database Type in our C# code, even if deep inside the business logic. Heck, the class even has a "Db" prefix, so the intent is clear.  In most cases this could just be a minor nuisance, but from an architectural point of view the NHibernate Spatial approach seems much more elegant and logic.

.NET Version
Well, NHibernate works perfectly with .NET 3.5. Not much to be said there. However, the spatial types of Entity Framework 5 (beta 2) only work in .NET 4.5. So, for projects to be released in a short time-frame, using DbGeography/DbGeometry doesn't seem like a viable option.

Support
I've already blogged about this. Basically NHibernate Spatial is a really nice boat that seems to be sailing without a captain. So, to use it will require an additional investment of time to set the boat on the correct course. If a crippling bug is found (already happened to me), you'll have to fix it yourself.
The spatial types in Entity Framework, being completely integrated with the Entity Framework library itself, will have the backing of Microsoft.

Setting Up
NHibernate Spatial is not that hard to set, but it's not a breeze. As I've demonstrated in a previous blog post, the mappings require special care.
Well, with Entity Framework everything just works out-of-the-box, including spatial support. You can even generate your model from the database and the spatial fields are set correctly.

Querying with LINQ
The spatial queries with Entity Framework work flawlessly. With NHibernate Spatial they do not. So, to use NHibernate Spatial to its full extent one has to use HQL, which can be a pain to maintain.


The Veredict
The spatial support in Entity Framework wins hands-down to NHibernate Spatial. From an ORM point of view, I actually prefer NHibernate to Entity Framework, but I'll seriously consider using Entity Framework if the spatial requirements of a project are of significant importance.

This concludes this very short series on Entity Framework 5 and Spatial Data.