When to use NHibernate | Jimmy Bogard's Blog:

But, if you draw your DDD bounded contexts well, you’ll find you need a lot less Big Bad Frameworks to get things done.

+1  This man's got it.

I'm adding a field to an insanely overly nested page in our .NET MVC system right now, and I'm having to edit, sheesh, I don't even know yet, maybe 8 files to expose it to our View?  I've got five levels of ascx files, about the same level of DTOs on the data pull side, and another set of nested files to access the ViewModels based on those DTOs. So I'm bucket brigading the field through the DTOs and AutoMappers until it hits the equally well nested ViewModel hierarchy, then traveling down our only slightly less layered ascx/View model to support it.

Or I could have added one extra field in a SQL statement (which could easily be a sproc) returning a DataTable, and I'd've been done.  I understand ORMs can be useful when preserving relationships programmatically, but is it worth the two three days I wasted learning our matryoshka doll data marshaling system?  Do we really do anything where that level of inter-entity manipulation occurs?  Hint: No.  The update calls are all pretty easy, since we're just updating one of the nested entities at a time, for the most part.  Send up an id and new values and poof.  No complex relationship management needed.

Hyper-monolithic [sic] pulls to modular puts makes myfreakinname something something.

Don't mind if I do.

Edit: I'm not alone.


You give the ORM a query, it builds SQL out of it, then it constructs a DynamicMethod to materialize data coming back from SQL into your business objects. I am not privy to the exact implementation, it may be including more or less work in these dynamic methods.

This implementation is an abstraction, and it leaks. It leaks performance, you give up some control over the queries you can run and have to deal with a LEFT JOIN syntax that is so crazy it can make grown men cry.

Or this "article" from CodeProject, which also later talks about Saffron's Dapper.NET, which the above link eventually gets back around to.

Over the years, I've seen several object-relational-mappers (ORMs) come along for .NET and always ultimately end up being somewhat disappointed with the end result. I remember seeing a preview of LINQ-to-SQL being absolutely blown away by the speed and ease with which you could generate code which would manage the movement of data between your relational database and your business object model. And all without having to hand-roll any SQL! A little later, it was Entity Framework which, at the time at least, seemed to be like LINQ-to-SQL but even better!

However, the time eventually came when I had to use some of these technologies in real-world development projects and it was then that some of their limitations became apparent. From cumbersome XML definition files to sub-optimal performance, I have spent so much time implementing 'fixes' and 'workarounds' to try and shoe-horn a framework into a project's architecture and get it to perform the way I want, that now (unless it is a very simple 1-tier application that needs to be developed rapidly), I prefer to go back to using the stalwart ADO.NET classes of yesteryear, as they offer the flexibility and control over my data access layer that I often find is taken away from me when using some of these ORMs.

I think I do this lamenting every three or four months.  I'm sure I've blogged about it before.  AAtF (Apologies After the Fact, natch).