Selecting an ORM for a .NET project: A real-world tale.

This is a story that I'm sure is being written over and over again by software designers like myself that need to develop relatively complex applications in a short amount of time. The only realistic way to accomplish this is to bite off major chunks of functionality by leveraging the work of others. Reinventing the wheel, especially wheels you know hardly anything about, can't be justified. Because of that many of the architectural decisions you have to make revolve around figuring out how to get all of those 'frameworks' and libraries and GUI components to work together. But I digress...

This post simply tells the tale of my journey though picking a framework for a project, how the landscape has changed over time, and what that means for the future. In case you don't want to read on, the ending is happy -- I think.

For any project that requires the storage and orderly retrieval of data there's pretty much no way to get around using a database. Also, if you have a requirement (like I did) that the user is able to select from a variety of SQL back-end databases then the use of some sort of Object-Relational Mapping (ORM) framework software is the only sane way to implement your application.

I'm not going to get into the details of ORM software or try to compare the features of the vast array of frameworks available. One current list of object-relational mapping software includes 34 entries for .NET (and another 27 for Java). One problem with making a selection is that many of these frameworks are constantly evolving and are thus moving targets.

On a side note, Microsoft has squarely thrown their hat into the ORM ring with the introduction of Language Integrated Query (LINQ) which is scheduled to be released with the 'Orcas' version of Visual Studio 2008 and .NET Framework 3.5 (see a summary here and a great series of articles on ScottGu's Blog). LINQ won't be released until next year so it couldn't even be considered for my project.

So, the question is: If you're developing a modest .NET application, how do you go about selecting an ORM framework? I'll walk you through the selection process I used.

General filtering criteria:

1. Non-commercial: I had no money to spend. This cut the possibilities about in half.
2. Open source: Even though I didn't want to touch the implementation, it was critical for long-term security that I had all the source code and build tools so it could be modified if needed.
3. SQL back-end selection: The framework needed to support at least four of the most popular SQL databases. I wanted the user to be able to select local and server-based databases that were both free (MySQL and SQLite3) and commercially available (Microsoft Access and MS-SQL Server).
4. Ease of use: The learning curve for some frameworks is steep. I wanted something that was easy to learn and to get up and running quickly.
5. Documentation and example code: Having a well documented API is important, but it's the example code and tutorials that teach you how to use the framework.
6. Support: This was the most subjective piece of the puzzle. The key is to get a sense of the level of developer and community involvement in the project. This comes from looking at the release frequency and history (in particular, look at the release notes and the number and type of issues resolved) and the level of Forum and/or Wiki activity. It's pretty easy to detect a dead project. Foreshadow: Just because it's an active project now doesn't mean it won't die in the near future!

To make a long story short, I ended up evaluating two open source ORMs: NHibernate for .NET and Gentle.Net. As noted above, I did this evaluation about a year ago (Summer 2006) and things have changed since since then. In any case, at the time I felt that the two were comparable for the functionality I needed which included just simple class to table mapping. The two major competing factors were ease of use (#4) and support (#6). NHibernate was clearly the more active project, but the Gentle.Net developers (in particular, Morten Mertner) were responsive to questions and quickly resolved issues that came up. I found Gentle.Net much easier to get up and running. In particular, in NHibernate you need to create a matching mapping file for every database class. This was daunting at the start and I felt like the split-file definitions would create a long-term maintenance problem. With Gentle.Net, I was able to use MyGeneration to create the .NET class which included the database field decorators, and that was it. Also, RE: #4 the NHibernate core is a 25MB download while Gentle.Net is less than 7MB. This is not only telling of the relative complexity of the frameworks, but it also means that there would be significantly more baggage that I would have to carry around with NHibernate -- and install on customer systems.

Based on that analysis it shouldn't be a surprise that I picked Gentle.Net. One year later I'm still happy with that decision. Gentle.Net continues to meet my needs and will for the foreseeable future.

OK, I'm happy, so where's the problem? The problem is that it appears development has stopped on Gentle.Net. I'm using the .NET 1.1 assemblies (1.2.9+SVN) with my .NET 2.0 application. The features in the next generation Gentle.Net (2.0) development looks promising, but at this point it doesn't look like it will ever be released.

In retrospect, I suppose that even with my concerns, selecting NHibernate might have been the better long-term choice. I think it was primarily the ease of the initial Gentle.Net implementation that had the biggest sway on my decision. Does this mean I made a wrong decision? You may think so, but I don't. There may be some cognitive dissonance going on here, but I did what I consider a reasonable evaluation and analysis and selected the best solution for my needs under the circumstances.

So here we are today. At some point in the future I will probably need to update or add a new SQL database that Gentle.Net doesn't currently support. I'll have to do something. Here are my options:

• Add the needed functionality to the existing Gentle.Net code base. This might not be unreasonable to do, but it's just putting off the inevitable.
• Re-evaluate current ORM frameworks and select one like I did last year. Déjà vu all over again... Microsoft side note: I can also wait for .NET Framework 3.5 to be released and use LINQ to SQL. My concern with LINQ is support for non-Microsoft databases. There's already some effort to develop LINQ providers (MySQL, etc. see here) but how long will it take to get reliable support for something like SQLite3 (or 4 by then) if it happens at all?
• Justify the expense and purchase a supported product.

I think my little tale is pretty typical. Any developer that's using open source components is, or will be someday, in the exact same situation as I am. Doing good software design to mitigate these types of issues is why they pay us the big bucks! 🙂

UPDATE (6/23/08): Here's a good take on selecting an ORM: Objectively evaluating O/R Mappers (or how to make it easy to dump NHibernate).