Last week I came across a post on Java Code Geeks about how “ORM haters don’t get it”. The author rambles on about how the arguments of the so-called haters are wrong, and he explains his understanding of ORM and how he claims that without using ORM from the start, every project eventually ends up with a home-grown ORM-like framework.

I don’t place myself in a group of ORM haters, and frankly I have to agree with the author that a lot of bashing against ORM is going on lately. Partly this is because other, more simple, techniques became available to interact with the database, such as the Active Record. Another reason is the trend of using NoSQL over relational databases.

Whether or not you use ORM, Active Record, NoSQL, or any other way to serialize data, is up to you. This post is not about data access specifically. What I want to talk about is the fanatic embracing of frameworks. We tend to put frameworks and other tools (such as the database) at the center of our application. Uncle Bob blogged about how the database is just a detail, last week. I want to include frameworks in this discussion.

Frameworks - most of them anyway - ease the implementation of application components and features. Sticking to the ORM example, ORM helps us to interact with the database by communicating with it in type-safe data structures. Another example is Google Guice that, though not in all cases, eases applying the Dependency Inversion Principle. These frameworks are indeed of great help to us, programmers. If you need ORM you should use an existing framework; it makes no sense to implement ORM yourself.

But that doesn’t mean these frameworks should be at the center of our application. An application is always about its use cases. Neither the customer nor its end users care about frameworks. Frameworks are implementation details, and use cases are at the center of our application.

How many times have you told a customer or end user, that the changes they want are not feasible because the architecture or a framework does not support it? The answer, most likely, is too many! Customers and end users do not care about implementation details, and they shouldn’t. They care about their own needs. The end users care about their processes and how to ease them, while the customer cares about its market.

So, then how must we work with frameworks? The answer to that is simple; do not embrace them! We should not trust them with our lives, nor with the life of the application! We must keep all frameworks at arms-length, keep them as details to the implementation.

If we keep those frameworks at arms-length, we can replace them when they no longer support our customer and end users. And I mean all frameworks, no matter how unlikely to change. If the customer or end user wants changes that the framework is not capable of, we replace the implementation with one that supports those changes. We should never have to tell the customer that something is not possible because of the frameworks we chose. It’s our responsibility to keep the options open, support and embrace future change, by deferring decision as long as we can. Any decision that you can defer, is a decision that you can change!

I strongly suggest you to watch Clean Coders episode 7, about Architecture, Use Cases, and High Level Design. In this episode, Uncle Bob explains why a good architecture maximizes the number of decisions not made.

From now on, be very careful with the frameworks you use, don’t trust them with your life, and make sure you can replace them whenever necessary!