.NET Musings

We had an interesting discussion the other night at the Cincy .Net Architecture Group about the place for ORM in development. I am a slow adopter, since I wrote my own layer using CodeSmith and the Enterprise Library. Fortunately, I developed it on my own time, so the code base isn't owned by any of my customers.

However, that last statement alone was enough to propel me into looking at ORM tools. If you've been following my posts, you know that I've been working through a proof of concept with NHibernate, and have been pretty happy so far. (Note: I had to take a detour on those posts, since I am creating a whole new WPF presentation with NHibernate for CodeStock - see sidebar for links to CodeStock).

The other motivation for the change to a true ORM tool is the fact that my framework is based on the 2.0 release of EntLib, and I would have needed to do some major work to migrate it to the 3.5 version. Why do the work myself, when I can leverage an existing tool with a significant user base and development group?

I am also a DBA/SQL Developer by trade, and active in the Cincy SQL Users Group, so one of the .Netters jokingly threw down the gauntlet to have me present NHibernate to the DBA/Developers of the Cincy SQL Users Group. The reason for the suspected animosity is the fact that the tools create the SQL "on the fly", and *ALL* in-line SQL is bad, or so the legend goes. But is it really? NHibernate creates parameterized queries, not just raw inline SQL.

While doing my research into NHibernate, I found an interesting post on NHibernate performance compared to stored procs by Bobby Johnson here. I found another article that went item by item through the Parameterized queries vs. Stored Procs debate here.

Bottom line, all we are talking about is CRUD. (I wouldn't recommend using ORM tools for reporting/etl/or other operations). As a SQL Server developer, I HATE to write CRUD. So, I developed templates in CodeSmith to rip through the database and generate all of my CRUD operations. As a C# developer, I HATE to write the code that wraps up the CRUD sprocs, so I developed templates in CodeSmith to rip through the database and generate all of my CRUD wrappers (code that creates the command objects, deals with all of the parameters, etc). Every productive developer I know is doing the same thing (perhaps using different tools like MyGeneration).

So, how much thought is going into the performance of the CRUD operations? I would say NONE! Now, when there is a performance issue, then the DBAs kick it into performance tuning mode. But, how much are the basic CRUD procedures looked at in this process? There are a whole host of other items to look into first that will have more impact (not much tuning can be done on select <fields> from <table> where <primary_key> = <int>).

In summary, I say throw away the CRUD! Use one of the tried and true ORM tools and stop wasting your time and your clients dollars writing CRUD code. But more importantly, would you rather be writing TSQL (or C# code) that solves the business problems at hand and makes you an indispensable asset that your company/client can't do without?

By getting rid of writing CRUD, you will certainly have Happy Coding!