blog.adamjcooper.com

This was meant to appear as a comment on Shawn Wildermuth's post "Are ORMs Solving Anything?". But it turned out to be too long to be accepted as a comment, so I've posted it here.

This is certainly thought provoking, though I'm surprised that the small consensus here is that ORMs are better suited for small projects. Because, in my experience, it is in the enterprise space that a good ORM (like NHibernate) can really shine.

I think we often assume that using an ORM means generating code or schema. With some ORMs, this is definitely the case. Why, LINQ-to-SQL generates reams of C# code to give you a type safe version of your data schema. And, as you pointed out, you can use tools like NHibernate to go the other direction as well, generating your data schema from your class mappings. If code/schema generation was what made ORMs great, then yeah, I think they'd only be good for newer, smaller projects. But there's a lot more to ORM than code generation that's worth keeping in mind.

In my mind, using a robust ORM (like NHibernate) really makes the most sense in an enterprise context. Here are some of the advantages of using NHibernate on a project of substantial size:

• Database agnosticism. If being able to provide a choice in database technology is an advantage to your business, NHibernate can certainly deliver. 

• Testing. As a consequence of being database agnostic, you can replace your heavy SQL Server with a nimble SqlLite instance at test time, allowing you to write blazing fast tests. 

• Caching. NHibernate offers a tremendous amount of options and control when it comes to caching. First-level caching is built in, and there are a variety of second-level caching providers you can chose from. Need to add distributed memory caching to your app? Plug into the NHibernate memcached second-level cache provider.

• Higher level of query abstraction. Most ORMs allow programmers to query in ways that are more consise (and type safe) than raw SQL. Of course, this can be a performance liability if you don't know what you're doing (or if you neglect to use a good profiler), but overall the productivity gain seems like a win to me. 

• Dealing with legacy data schemas. A framework like NHibernate offers significant advantages when working with a large, legacy codebase and database that need to be maintained. With it, I can start modeling my own view of the world in code (in a DDD style) and then use NHibernate to map my objects down to the way they are actually represented in the database. Having done that, we can then start querying our domain model directly, allowing the development team to think in terms of the way we think of the business rather than having to constantly translate our intent to a data schema that hasn't grown with the business. And, once we've abstracted away direct access to the database, we can more safely modify the database schema knowing that it is only our mappings which will need updating.

I'm sure someone with more ORM experience than me could add a lot more to the list. But notice that none of the points above are particularly suited for small projects. In fact, quite the opposite. All of these gains are relevant when developing larger projects for the enterprise.

So I suppose what I'm suggesting is that code and schema generation is only a small part of what ORMs offer. Of course there are enterprise situations where performance is so important that an ORM tool is simply not appropriate, but few of us are Amazon or Google, and I would argue that the advantages listed above make long-term maintenance, changes, and refactoring significantly easier rather than more difficult.

I hope this reply doesn't come off as defensive, because, like you, I'm not trying to chose a pro- or anti-ORM side. But I did want to point out some ways in which ORMs can be very helpful in managing large projects.

I do wonder what the future holds for ORMs though, particularly with the rise of functional programming. A language like F# can deal with relational data in a much more natural way than most of the OO languages we've been using for so long, and I wonder how that might change the ORM landscape.

Your chart on the right side of the page illustrates something that astounds me--look at how much stuff we have to do above and below the business objects, which are the real heart of the software! It's amazing how much effort and energy we expend on all of the infrastructural pieces that we need to put in place in order to get real work done. Then again, perhaps the better way to look at it is that we're trying to extract that sweet core of business knowledge out of and away from all of the infrastructure concerns (both front end and back) so that we can swap out the pieces that change without destroying the code that models our business. And that is, I think, the real reason I find value in an ORM.

Hope that helps,

Adam