Random Code

I was doing my usual morning troll through my rss reader when I tripped over this post from Jeremy Miller about the Entity Framework and the vote of no-confidence.  I am not qualified to comment on the EF as I haven’t even thought about looking at it yet.  While I was scanning his post I came across this link to a post by Stephen Forte (follow this link to find out who he is – I had never heard of him till today, but I have heard rave reviews about Telerik of which he is the Chief Strategy Officer).   I normally wouldn’t respond to a post on something I consider myself a novice at but the comment (below) pissed me off enough to warrant a reply.

My second major problem with ORMs is that ORMs are a solution to a problem that should not be solved. Developers who write object oriented and procedural code like C# and Java have trouble learning the set-based mathematics theory that govern the SQL language. Developers are just plain old lazy and don’t want to code SQL since it is too “hard.” That is why you see bad T-SQL: developers try to solve it their way, not in a set-based way.

First, lets get the pissed off, insulted developer response out the way…

I know and understand set based math.  I have written some pretty complex SQL to solve some rather hairy problems.  I have used various dataset / code-generated driven table gateway approaches.  The best data access layer (as opposed to object access layer or ORM) I have ever used is the one I never had to use.  NHibernate / Rhino Commons / NHQG and a little bit of glue gives me business object that contain all my rules (behaviour) and the associated data (state) and they do it in a consistent, performant and elegant manner.  I do not consider myself lazy or inept, I want to solve the problem in the best possible way in the shortest possible time and for any system with more than a little logic using domain objects is more often than not the best approach.

Now we can deal with the argument presented in the orginal post.

My first problem with ORMs in general is that they force you into a “objects first” box.

Object first design allows you to focus on the business concerns without worrying about the database constraints – yes you have to be aware of them butyou can optimise where there is a performance issue (premature performance optimisation must rank as one of the seven deadly sins of software design and development).

Database first design often constrains your system and forces it to contort to meet changing business requirements that crop up during development (been there done that), it wasn’t that the database was poorly designed in the first place, we just didn’t forsee certain needs that cropped up later.  Database first approaches are valid, particularly where you are working over a legacy database, however I think that in the general case you get a better result if you can ignore the database initially.

IMHO focusing on both database and object design at the same time requires too much of a split in concentration and way to much context switching.  I would argue it degrades the design process by reducing coherent trains of thought and interupts the building of that (all important) internal view of the business model with which you are working.

Design your application and then click a button and magically all the data modeling and data access code will work itself out.

Any developer who is looking for a “magic button” approach is most likely a highly skilled “Microsoft Developer” who really wanted a visual designer but couldn’t find it so has to resort to “clicking a button and magically have the data modelling and data access code worked out”.  I’d rather not have one of these developers on any team I work in, thanks.

This is wrong because it makes you very application centric and a lot of times a database model is going to support far more than your application.

I find it interesting that ORM is equated with “application centric”, looking around at most of the people using ORMs like nHibernate, I’d hazard a guess they are more focused on delivering business value than the guy sitting at his visual designer trying to make sure all the aspects of his dataset diagram line up just right.  I think using an ORM frees you from the database, this allows you to concentrate on the business aspects of the system, which allows you to deliver business value, not just a pretty digaram and a place to store a bunch of state.  Modern applications designed to support businesses are more than just the data in the database, they are the rules that govern that data and the transitions the data go through.  Without these rules it’s all just data, with these rules it is a goldmine of information and a treasure trove of process automation and increasing efficiency.  The application is not just the database or just the code, it is the synergistic coupling of both parts to create something truly useful.

In addition an SOA environment will also conflict with ORM.

Why? Where will the conflict occur? What will cause the conflict? As I said above, the database is simply a state repository, it isn’t the application. In an SOA environment the web services should be leveraging the objects to achieve the business purpose being exposed via http and angle-brackets. Yes there are issues associated with shipping objects on the wire, but they can be worked around. The benefits of providing the client with a rich business object that contains the rules required for working with it far outweigh the amount of work you have to put in to get those objects onto and off the wire.

I’m going to ignore the second problem (I’ve already had my rant on that).  From what I have seen to date, it is usually the enlighted developers who seek out ORMs, these are the ones who have been through dataset and stored procedure wars and come out the other side wiser (and battle scarred).

The sad thing about this post is that one very valid point is made but lost in the noise …

an ORM will not solve all of your data-access needs

however with a bit of work and a good understanding, I think you can get pretty damn close.