I read a really good post from Vic on his move away from ORM frameworks. I did not agree with everything he said though and wanted to start a discussion. Unfortunately, there is no way to leave comments on his blog. The next best thing is to post it here.

There are some niche tasks where I still use an ORM despite the costs mentioned by Vic and myself. An ORM is great for creating dynamic queries. As we build more rich front-end web applications, it is very easy to build queries with user specified filters and sorting. Trying to do this manually is time-consuming and often bug prone. I find this setup particularly useful when building administrative pages that are looking at lists of things like users or orders. Performance is not a real big issue here and the queries themselves are usually only joining one or two tables. There is still the risk of a runaway query wreaking havoc on your master database. To combat this scare, I advocate a separate slave database to run queries like this.

Vic mentioned that he puts the SQL directory in the controllers, but I think this is a mistake. Controllers are tying the view to the model and should not contain any other logic. I prefer to keep business logic at the library level and data access logic in the model. The controller can consume library or model classes at will and pass them over to the view for output. This may seem like an extra step that is not needed, but it makes testing much easier. There is also the added benefit of being able to write a service layer or API with very little effort should the need arise.

All in all I think Vic makes a good argument. I think developers need to learn to embrace databases, SQL or NoSQL, instead of trying to abstract them away. Data is often the most important part of the business and it should be treated as such.