Users don't care about the middle

If you are reading this you are either a developer, strange or both. But you are also a user. Let's think like a user for a while. What do you care about? Me, I care about two things:

• The user experience - This generally means a good GUI, whatever that is depending on the situation.
• My data - I want my data to be stored in a reliable storage and accessible when I need it.

What is missing from this list? Answer, the middleware.

As a user I don't care too much about the exact kind of database, what languages were used in writing the software, etc. I definitely don't care about all intermediate forms my data have taken from the database to produce pixels on my screen. I tend to think about my data as data.

I really think this is the focus we as developers should have as well! Before deciding on you technology stack, we should think long and hard on the problems we are trying to solve.

What does this to have do with ORM?

Ok, but this is a ORM-bashing blog. What does this have to do with ORMs?

I really believe that ORM is a trap what seduces you into putting your precious brain cycle working on the wrong problem. It promise goes something like this:

"If you create a nice class diagram you will never have to think about your database again. Don't be afraid to add some inheritance as the elite OO-developer you are. And if you don't know anything about relational databases that's ok, you are so cool with you OO-skillz. Oh, and I will almost auto-generate the GUI for you. One page per class was what you wanted, right? I love you. Look at this tiny pet-store example how good it works."

And with this in mind you start hacking away not thinking to much about database constraints and the database schema sort of just happens, it is a second class citizen.

(Of course, the ORM proponents will say that you can go from schema to classes as well as the other way around. But if you do that I really think you should pause for a moment and ask yourself if you really need the added weight and complexity of an ORM?)

When you are done with your object graph you can start to think about the GUI. The problem is, there is not much to think about. Your entity classes have more or less dictated what your GUI will look like. Cut your data any other way and you are in for-loop-add-things-to-maps-and-loop-some-more-hell. Without an ORM this would be a simple declarative SQL statement.

And do you know who don't care about your fancy object graph? Your users.

The alternative

So what happens when you do the opposite and start focusing on the GUI and the database. Well, if you are in a RESTful AJAX web-application setting you will notice that your middle starts to get really really boring, which is a good thing. And if you drop the ORM it will even get simple.

Your middleware will become a simple servant of data, transforming data from whatever format it happens to have in the database to another format suitable for sending to the client. If you adhere to the state transfer part of REST (and do not use AJAX as another RPC-protocol) you will see other winnings as well, such as it doesn't matter anymore if the next request goes to the same server.

You will get more time building that awesome application for your users, you know the ones who puts food on your table. And you you will no longer complain when they ask for features what don't fit your fancy object graph. You will be able to take advantage of the features people used to use as an argument for choosing a SQL database to begin with. Before, when people used to know that a database is more than persistent storage.