My co-worker (Kris) and I have been evaluating several OR/M apporaches for our current refactoring of a system that is very clumsy. The current system is an artifact of poor design and uses a very clumsy EF apporach in which business layer information is skewed across all layers on the project. This ends up with a very spagetti like peice of software, and as neither myself or Kris created the project initially, leads us to very long and frustrating episodes to try and fix even the most trivial of bugs. We have tried multiple things to help this and to put off the inevitable, we introduced sophisticated logging, we introduced minor refactors, but all has unfortunately lead us to the one solution – a major code refactoring.

While this is a great way to clean out the code and start from scratch – It’s a very daunting process, and no-one likes refactoring entire projects (especially one as big as this) from scratch. After spending a few weeks and months investigating and playing with different options I am in the process of evaluating a few OR/M’s for the new project.

Wanting to take a DDD approach this times we have spent a bit of time actually building a few different Model Layers (to be consistant with our overall MVC approach for the websites). Which utilise good DDD Practices for testing our total solution. As the final solution is going to be providing an ORM layer for many facets of our solution (MVC Website running on 3.5, WCF 4.0 In Development Workflows) we wanted to make something as scalable as possible.

So we started evaluating how Entity Framework 3.5, 4.0, nHibernate (with fluent nHibnerate and nHinbernate.Linq), ActiveRecord & Subsonic would adapt to our solution. I come from a Ruby background, and while being very familiar with ActiveRecord, the lack of PI and ineffective ability to adapt to the DDD model that myself and Kris wanted to apply unfortunately wrote that model of the list first. Also the fact that Castle ActiveRecord hasn’t recieved a checkin since 2007 was something that really worried us. The current project uses EF1.0 and so for pure use of familiarity we started on this first.

At the time of writing we are yet to choose which ORM we are going to use, so suggestions would be very helpful. Here are some of the advantages and Diadvantages we have come up with for each OR/M thus far (To be updated as I find more).

Entity Framework 3.5
Pros

• Can already work on .NET 3.5

Cons

• No Poco
• Poor Enum Support
• Projection Transform not Supported
• No PI

Entity Framework 4.0
Pros

• Poco Support
• PI

Cons

• Can not already work on .NET 3.5
• Some Pollution involved for Enum Support
• Projection Transform not Supported

nHibernate 2.1.0 + nHibernate.Linq + fluent nHibernate
Pros

• Can already work on .NET 3.5
• Lots of DDD Documentation (In books & Blogs).
• Projection Transform Supported
• PI

Cons

• Pollution in Poco needing to use Virtual
• Pollution in Poco with relationship Fixups
• Some LINQ features may not be supported (TBA)
• Composite keys with Fluent nHibernate is tedious beacuse we have to override GetHashCode() and Equals()

Subsonic (Yet to be evaluated)
Pros

• Exceptional LINQ Features

Cons
ActiveRecord
Pros

• Ruby on Rails style OR/M
• Easy to define models

Cons

• Does not fit with DDD Patterns
• No PI / Persistence Pollution in Business Objects
• Can be sluggish and sloppy in complex systems.