What are the criteria for evaluating an ORM for.NET?

Question

I'm looking at evaluating ORMs.

I've used SubSonic, Linq-to-SQL and Entity Framework. I've got a team of developers ranging from juniors to seniors.

What are the criterias for evaluating an ORM for.NET?

Answer 1

It's a loaded question.
There are lots of very good ORMs approaching the subject with different philosophies.
None are perfect through and all tend to become complex as soon as you stray from their golden path (and sometimes even when you stick to it).

What you should ask yourself when selecting an ORM:

1. What does it need to do for you?
   If you already have a set of requirements for your application, then you should select the ORM that better matches these rather than an hypothetical 'best'.

2. Is your data shared or just local?
   A lot of the hairiness in ORM is caused by how they handle concurrency and changes to the data in the database when multiple users are holding a versions of the same data.
   If your datastore is for a single-user, then most ORMs will do a good job. However, ask yourself some hard questions in a multi-user scenario: how is locking handled? What happens when I delete an object? How does it affects other related objects? Is the ORM working close to the metal of the backend or is it caching a lot of data (improving performance at the expense of increasing the risk of staleness).

3. Is the ORM well adapted for your type of application? A particular ORM may be hard to work with (lots of performance overhead, hard to code) if it's a used in a service or sitting inside a web app. It may on the contrary be great for desktop apps.

4. Do you have to give up database-specific enhancements?
   ORMs tend to use the lowest-common denominator set of SQL to ensure they work with lots of different database backend.
   All ORMs will compromise on available features (unless they specifically target a single backend) but some will allow you to implement additional behaviours to exploit specific enhancements available in your chosen backend.
   A typical db-specific enhancement is Full-Text search capabilities for instance; make sure your ORM provides you with a way to access these features if you need them.

5. How does the ORM manages changes in the data model?
   Some can update the DB automatically within a certain measure, other don't do anything and you'll have to do the dirty work yourself; other provide a framework for handling change that lets you control database updates.

6. Do your mind to couple your application to the ORM's objects or do you prefer to handle POCOs and user an adapter for persistence?
   The former is usually simple to handle but create dependencies on your ORM-specific data objects everywhere, the latter is more flexible, at the cost of a bit more code.

7. Will you ever need to transfer your objects remotely?
   Not all ORMs are equal when it comes to fetching objects from a remote server, look closely at what is possible or impossible to do. Some are efficient, others not.

8. Is there someone you can turn to for help?
   Is there good commercial support? How big and active is the community around the project?
   What are the issues existing users are having with the product?
   Do they get quick solutions?

A few ORMs that I looked at:

• XPO
  From developer Express: is small and simple, code-centric. They use it for their application framework eXpressApp.
• NHibernate
  Is free, but the learning curve is rather steep. Lots of goodies but it's hard to find what is really relevant sometimes in all the fragmented documentation.
• LLBLGen Pro
  very mature project, not the simplest but a lot of thought has been put into it.
• Entity Framework
  GEtting there. The last releases are pretty good and MS is listening, although it's still a bit young compared to other more mature ORMs.
• DataObject.Net
  Looks promising but is also a bit new to risk an important project on it IMHO. Quite active though.

There are many others of course.

You can have a look at the controversial site ORM Battle that lists some performance benchmarks, although you have to be aware that raw speed is not necessarily the most important factor for your project and that the producers of the website is DataObject.Net.

Answer 2

ECO :) It is much more than an ORM while including state machines and executable OCL (namely EAL) supports. There exists a free version with a 12 domain classes limitation which I think should be pretty neat for small projects.

Answer 3

I'm using NHibernate and have found it pretty good.

In my case, linked to an MS Sql database, but you can connect to other databases.

It doesn't take long to get up and running - just map your object to the model - I use an xml file but you can do it fluently in code. There's a great community, and personally I have found Ayende's work to be very helpful - I use NHProf which is an sql profiling tool.

I mostly use the out of the box functions - straight object mapping, but I've also use the Hibernate Query Language, which is pretty easy to get a hold of.

Answer 4

Sadly, in my last three jobs, we had three home-grown ORMs. In each case, they mostly sucked for varying reasons.

I have recently been evaluating Entity Framework 4 and its POCO support (a nice walkthrough is here) and am really impressed at how nicely it stays out of my face and makes me feel like I'm programming again rather than herding data.

Answer 5

I would advise you to have a look at DevExpress XPO. This along with DevExpress XAF will make life of any developer easy once its learning curve is crossed.

Answer 6

There isn't a "best" ORM framework because they all have different combinations of strengths and weaknesses and it tends to be the case that if developers choose to focus on making one area better there are other areas that suffer in comparison (code first vs model first vs database first).

There are, on the other hand, a number of very good ones some of which will be a better match to your personal circumstances and philosophy than others.

---

Edit: For what its worth, I'm currently using Linq to SQL - mostly because its there though partly because it does a lot right for minimal effort and will probably progress to Entity Framework again "because its there" (though similarly there is also a lot about EF4 that's right as well as some stuff that's wrong). The concern, especially with the latter, would have to be performance but for most of my cases that's not a huge issue and the ability to run Dynamic Data and OData from the models (L2S and EF) has considerable benefits for me in terms of "cheap" wins.

Answer 7

I like Linq to Sql a lot. It's simple and has a decent designer. However, I hope to end of life it in favor of Entity framework. I would like to be able to leverage the ability to modify the generators so that I can have customized objects.

The biggest benefit that these have over others (in my opinion) is that they are out of the box with VS. This is also a negative in that you are at the mercy of MS (see Linq to Sql).

Answer 8

We use NHibernate + Fluent NHibernate, with Linq-to-Sql on small projects. The reason for this is:

1) (Not the primary reason) NHibernate seems to have a higher "respect" factor amongst developers (is this true?),

2) Compared to linq-to-SQL, nHibernate allows ORM mapping between Db objects and entities which don't map 1-to-1,

3) We haven't extensively compared nHibernate to Entity Framework 4.0 but here's a good comparison: http://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx

nHibernate does have somewhat of a steep learning curve and its XML maps can be quite verbose, but start with with the Fluent Nhibernate site documentation and work your way backwards.

Answer 9

ORM Comparison and Benchmarks on ORMBattle.NET

Answer 10

We've had good luck with Entity Framework. Our situation is somewhat unusual, though -- we do data collection for the reporting team, so they actually design the database. We get the DB and then just use EF to generate the data access classes from it. Works great for us, but we just do bulk data loads, so I can't vouch for how well it does in a more transactional environment.

Answer 11

NHibernate (+ FluentNHibernate) would be the default option for me. It is very flexible, extensible and robust. It's got a huge amount of users and it's very actively maintained. The downside is the steep learning curve.

MindScape's LightSpeed is simple and user friendly, but still fairly flexible and capable. It has a designer surface like L2S/EF and a UnitOfWork implementation.

Answer 12

[DISCLAIMER: I work for DevExpress]

You can see screenshots of typical applications created by DevExpress application frameworks here. This page also contains a very brief review of our products. For more detailed information on why, I suggest you check out respective product pages on our web site.

As for DevExpress XAF and XPO, here is a good explanation on why to choose our application frameworks. Plus, we provide support and documentation, which is also important and worth mentioning. Feel free to contact us in case of any questions.

Answer 13

Well, there is no "best" choice but I would say that regular old Linq to SQL meets your needs. It's not a "true" ORM per se, but it's very lightweight and gives you the flexibility to write code without being aware of it, if that makes sense. What I mean is that you can continue writing code as normal, without having to really be aware of Linq other than having the dbml file(s). You can still write abstractions over it, using the Repository or Gateway patterns, and L2S fulfills the main role of an ORM, which is to get around the Object-Relational Mismatch.

Entity Framework is a bit heavy, and while I've only dabbled with it a little bit it's more "in your face" than basic Linq to Sql, but EF is much more of a true ORM than Linq. I would look at all of the criteria you are looking for in an ORM. Is it just because you want to avoid having to write raw SQL or, worse, have hundreds of Stored Procedures? Do you need some extra features that raw Linq to Sql can't provide? You need to answer those questions, but based on your brief requirement ("lightweight and easy to use") I think Linq is slightly easier than something like Subsonic, and is built-in to Visual Studio.