"Another Software Engineer who is working to feed his family"
Thursday, October 7, 2010
What is the best ORM for .NET ?
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:
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'.
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).
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.
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.
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.
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.
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.
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:
From developer Express: is small and simple, code-centric. They use it for their application frameworkeXpressApp.
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.
very mature project, not the simplest but a lot of thought has been put into it.
Still a bit early IMHO. It's promising, but there are some basic stuff that other ORMs provide that are just now being tackled (auto-generating DB from code for instance).
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.