My friend and I were discussing several frameworks which led me to think about some of my preferences for different systems. Having worked with several ORM type of frameworks like Hibernate, ActiveRecord (Ruby On Rails), Zend and Kohana in addition to several in-house systems, my general conclusion is that most ORMs beyond simple CRUD and basic query operations end up sucking badly. ORMs do is attempt to map your model type of objects to your database layer and make the database aspect more transparent.
For the most part, I like the idea of not having to deal at the infrastructure level and prefer depending on the system to figure this aspect out for me. When you want to invoke more complex type of queries, ORMs end up falling apart badly, resulting in you having to learn and use their version of a query language so that you can pull data out in a relatively efficient manner. Some people might naively use the mapping aspects of an ORM, where the system may not necessarily pull out data using the most effective query. Unfortunately, you’re forced to rely on such a mechanism and see data retrieval at a pretty poor level.
At one of my previous companies, we had our own model type of layer, which handled your basic CRUD operations just fine. However, for most queries we ended up just writing raw SQL, pulling out the results into a simple array then storing those results in memcache. The nice thing about doing it in this fashion is that we could individually analyze each query and optimize them accordingly. The only downside was the manual re-writing of a certain type of code that became repetitive and probably could’ve used some other method to split some of the tasks up.
Some people might argue that when you go that route, you end up becoming too attached to your database. Honestly, after working in this industry for 13-14 years, I will say this: how many times you really switched out the database system for a completely different proprietary one? It’s a stupid argument that I’ve never seen put into practice. Some people talk about legacy systems, but I think it was one of stupid selling points of EJBs back in the day (and look where that’s at these days). The other thing is that most people end up coding around situations that may require some sort of back end replacement. Generally, it’s not the entire back end that needs to be replaced but the structure as scale might be the influencing factor here. If you do this, you probably are not going to keep your back end code the same anyway.
The thing for me ultimately is that the model/ORM layer ends up becoming unnecessarily complex and sometimes extremely heavy for something that should be far more simplified. Certainly, the idea of using an ORM (and many of which end up being written in house anyway) sounds sexy, but in the end I haven’t really felt that this layer offers much benefits in the long run. Compare that to a simplified data access layer where you use something like a data repository pattern to handle most of your generic CRUD operations then employ specific methods for data retrieval and maybe adding a caching layer. If the data is just kept as something as simple as arrays containing associative arrays/hashes, you can avoid the overhead of having really heavy/fat objects taking up more memory than required.
Lastly, I don’t know how some of these systems are incorporated to the newer NoSQL type of backends. Quite honestly, I doubt that any of them do, despite the fact that this may be one of the few rare cases where you might switch out part of a backend system.