I never understood the ORM hate/bashing. It's like the framework fanboy paradigm. "I love framework X, and framework Y sucks!" They are tools built to help sol

I never understood the ORM hate/bashing. It's like the framework fanboy paradigm. "I love framework X, and framework Y sucks!" They are tools built to help solve a particular problem. ORMs are great when dealing with CRUD operations on entities and remove the need to write tedious boilerplate code every time. On the other hand, ORMs can be misused and cause all kinds of performance related problems. Most obvious use-case is developers that don't have much experience with databases, and instead of choosing to perform processing of data in the database run-time, they fetch data through the ORM and write poor performing code riddled with business rules in the application layer. I think it's good to take a step back and understand that the ORM is a tool, which when used for the purpose it was designed for, works well. Complex joins and queries can still take advantage of an ORM. One example is using materialized or non-materialized views, which can then map to an Object using the ORM to query it. That way the bulk of the processing is done in the database runtime, and simply accessing the object is done through the ORM. There's also the separation of concerns. A seasoned developer will opt for creating a well defined schema, and baking business rules into the database layer, because he knows that a well designed, and highly normalized data model will outlive any application where the business rules are housed in the application layer. All things considered, I do love the ActiveRecord ORM design-pattern. I've worked with hibernate, JPA, and some other ones in the past, but ActiveRecord as employed by Rails and Django, is still my favorite.