Framework is everywhere in our every day life as a software architect or a software developer. Struts, Spring, Hibernate, Axis, jBPM, just to throw out a few popular names in a Java developer’s world.

We choose the right framework, we learn the framework, we adjust the framework to suit our needs, we suffer from the bad design of a framework, or, what the hell, we design our own framework! It invades our vocabulary, “What’s your MVC framework?”, “Do you use Spring or EJB?”, “Have you migrated from Toplink to Hibernate for your persistence layer yet?”. We think (and even dream) in frameworks cause they are so fundamental to our work, no matter we like or hate them.

But, why do we use framework at all? Can we live without any frameworks? What are the benefits and pitfalls? When should we use framework and when should avoid it?

We seldom stop and ask ourselves these hard and fundamental questions. Now, it’s the time.

What’s a Framework?

The definition in Wikipedia says, “A software framework, in computer programming, is an abstraction in which common code providing generic functionality can be selectively overridden or specialized by user code providing specific functionality.”

“Frameworks are similar to software libraries in that they are reusable abstractions of code wrapped in a well-defined API. Unlike libraries, however, the overall program’s flow of control is not dictated by the caller, but by the framework. This inversion of control is the distinguishing feature of software frameworks.

The comparison of framework with the software libraries is well worth attention cause that reveals the key nature and advantage of a software framework.

In other words, the framework defines the architecture and workflow and other codes are simply “plug-ins”. That’s why it’s named “frame-work”. It laid out the “frames” of the architecture. Other codes are simply fill-in the “emptiness” among the “frames”.

Framework is like a high level blueprint for a house. It defines how the house is going to be built, how the water and electricity will be flowing, and how the rooms are connected. Once we have that, the big decisions are already made. We just need to play with the rules, follow the standards and make decisions about details.

Why Framework?

The definition of framework already answered the question. To build any complex software systems, we have to have a high level architecture design. Even a specific layer, like UI or persistence, we need to have such a design. As long as we use the same design at least twice, it becomes a “framework”, a set of common codes providing general functionalities.

So, the only way to avoid using framework is to do everything differently every time, in anther word, “reinventing the wheels every time”. Obviously, although it’s challenging and interesting, it may not be the most efficient and cost-effective way to build useful applications. Thus, we have to live with frameworks. We are doomed.

Architecture design with Frameworks

Well, there is no reason to be discouraged as architects and developers. Using frameworks doesn’t means we are deprived of fun and creative works. On the contrary, it requires more creativity out of us.

First of all, we are the still the one determining the overall architecture. There is no “master” framework that solves all the business problems. We need to make some fundamental decisions about the architecture like whether to use thin client or fat client, centralized server farm or geographically distributed servers, the abstract layers of the architecture, etc.

We do have some guidelines and industry best practices to follow. But, usually, those are out of the scope of “frameworks”. We have to rely on our experiences and the deep knowledge about the specific business challenge we are facing to make the right decision.

Secondly, when it comes to the design for each abstract layer like UI, business logic, persistence, etc., where the frameworks are most helpful, we need to pick the one that fits the need most from many available frameworks. For example, there are more than 30 business process management frameworks to choose from. It can be a daunting task to pick the right one. Also, there are many occasions when no such “perfect” framework available. That’s the time we start to build our own and the fun starts.

Thirdly, most of the time, we will find some existing framework and start to build our application upon it. We need to be a quick learner to familiarize ourselves with this new framework. Most likely, the framework will provide more functions than we ever need to use. What to learn and what to ignore always a challenge to our talent. Buying the most popular book like the “Spring in Action” and reading it from beginning to end may not be the most efficient way. Starting coding right way with some helps from the “Hello World” application may also limit our capabilities to most efficiently use the framework. Sometimes, the framework provides many options. We almost need to define our “framework” of “framework” to help the team to make the best use of the framework. We need to creatively figure out the best way for us to approach the frameworks.

In conclusion, frameworks are not limiting our creative thinking. Instead, it enables our creativity, gives us something to build upon and gives us the platform to creatively solve the problem we are facing.

Unanswered Questions

We now know the importance of the software frameworks. But, how can we pick the right framework? How to determine if we should build our own instead of using the available ones? Should we turn every body of codes into a framework? I will cover that in my next post.

As always, your comments and thoughts about frameworks are more than welcome.