Back in June 2006 Ted Neward wrote an excellent article about ORM titled "The Vietnam of Computer Science". Two years later we conclude that we’re still stuck in Nam, and it’s only getting hotter…

nHibernate is now maturing and a beta of their second major release (2.0) was just released. After the failures of Object Spaces and WinFS it looks like Microsoft is stepping up their data programmability efforts with two ORM offerings, LINQ to SQL (part of .NET 3.5) and ADO.NET Entity Framework (releasing in .NET 3.5 SP1). Some developers are fearing (or hoping?) that LINQ to SQL might be the next casualty of war, as there really hasn’t been a lot of improvements or announcements made around LINQ to SQL after its initial release, as expressed in the post "Is the ADO.NET team abandoning LINQ to SQL".

Things got really hot for the ADO.NET Entity Framework team last week, as a "vote of no confidence" was put out. So far it’s signed by 392 developers. Tim Malalieu, program manager on the EF team, responded with a detailed post addressing the concerns rose in the "vote of no confidence", and it’s good to see Microsoft responding to the concerns of the developer community. Microsoft has also put together a council including Eric Evans, Martin Fowler, Paul Hruby, Jimmy Nilsson, and fellow Regional Director Stephen Forte.

Stephen did a great post on his take on the whole ORM debate this weekend, and I figured commenting on it would be a good way of getting "back into blogging" after being quiet for almost three weeks. I mostly agree with what Stephen is saying, and one of the points he makes is about embracing the impedance mismatch rather than trying to ignore it:

So ORMs are trying to solve the issue of data access in a way that C# and VB developers can understand: objects, procedural, etc.  That is why they are doomed to fail. The further you abstract the developer from thinking in a set-based way and have them write in a procedural way and have the computer (ORM) convert it to a set-based way, the worse we will be off over time.

What I am saying (and have been saying for a long time) is that we should accept, no, embrace the impedance mismatch!  While others are saying we should eradicate it, I say embrace it.

One of the things I love about C# 3.0 and LINQ (not LINQ to SQL) is how it gives you a nice way to work in memory data in procedural code. I’ve seen heaps of examples of bad code with several levels of nested for-each loops “mimicking” set based operations. In many cases these big chunks of codes can be simplified to one simple easy to read LINQ expression. But, then again perhaps the problem could have been solved in the database in the first place..?

The ironic thing I’m now seeing is developers who are lazy and don't want to learn SQL using tools that will produce SQL for them. The SQL is bad, and now those same anti-SQL lazy developers are struggling to read pages of generated and near-unreadable SQL trying to solve performance problems. They’re dealing with SQL that’s more verbose and orders of magnitude harder to understand than what was needed in the first place!

This brings me nicely to the reason for my lack of blogging the last three weeks. I’ve been too busy doing database integration and reporting work for a medium sized organization here in Melbourne. The problem I was faced with was establishing a platform for data integration between line-of-business applications to do management reporting. The organization had a basic reporting solution today consisting of a set of VB- and Python scripts being executed by scheduled tasks to pull the data into a report database. The actual reports where generated by an ASP.NET 1.0 application that populates data grids. As you can imagine this is no ideal solution, and is both hard to maintain and extend, and really doesn’t solve the business need of the customer. When the exciting solution didn’t give the reports they needed they had to do manual Excel reports.

The developer in me who loves shiny new framework might see this as an opportunity to migrate the exciting solution to something sassier, say ASP.NET MVC + ADO.NET EF, and perhaps a dash of Silverlight to show some great KPI's. Thankfully I keep “cool” and did the reasonable thing (the "right tool for the job"-cliché): SQL Server Integration Services and SQL Server Reporting Services. I solved the problem by building the SSIS packages based on the exciting scripts, and complimented them with additional imports where needed to meet new requirements. During the report authoring (something I did together with one of their business people who knew what reports they need) I discovered how “rusty” my SQL skills had become. It took a couple of days to "loosen up" and be completely up to speed with writing joins, groupings, aggregators and more to get the reports they wanted. I think this is the case for more and more developers these days.

The database engines are becoming more and more powerful, yet I suspect the average developer to take less and less advantage of this power. By writing "dumb plumbing" code to populate .NET objects we forget the power of the database, and think everything now can be solved by putting a ORM on-top of the database.

That being said I do think the ORM has its place in application architecture, but as any tool you need to learn how to use it right, and know what problem it can solve. Personally I love using ORM for my simple CRUD operations, and whenever needing you can always drop down to hand written SQL. I remember when I did my first ORM project on an early version of LLBLGen back on .NET 1.1. We didn’t have partial classes, so any modification made to the auto generated code had to be written between special region comments that didn’t get overwritten when doing a regeneration of the code… We’ve come a long way since then.

And for the project I’ve been working on: We delivered today, on time and above expectations. The customer already had SQL Server installed (and SSIS and Reporting Services, perhaps without knowing), so deployment was a breeze. The new solution is easier to maintain and extend by the customers IT organization, and offers a unified way to do reporting and data integration. And as for sexy Silverlight 2 KPI gauges we didn’t get time to do it this time. By using Reporting Services to export to XML I’m sure we could do something cool within this framework. Well that’s a whole different blog post...