In previous articles, I talked a lot about the Model/View/Controller design pattern. Using it is recommended for all programming projects in the same way it’s recommended to pull a parachute’s ripcord when sky diving. The more independent (loosely coupled) each MVC tier is in relation to the complexities of the others, the more likely our applications will survive maintenance changes and enhancements. Equally I demonstrated how loose coupling can be employed by using JSP and JavaBeans.

So we’re set to develop that enterprise project our boss just put on our desk, right? Not really. An enterprise application will get very complicated, and it will get there very fast. Program features will interact with each other creating a ridge overall design. Endless hours will be spent solving problems over and over again. New features will be added, and old features will be removed or changed. And on it goes.

Here is another “ripcord” recommendation: get acquainted with Java design patterns.

Four eggheads (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides), nicknamed the Gang of Four or GoF, with a lot of time on their hands created a set of programmatic design patterns. Their book, Design Patterns: Elements of Reusable Object-Oriented Software (ISBN 0-201-63361-2), describes recurring solutions to common problems in software design. The book is divided into two parts, with the first two chapters exploring the capabilities and pitfalls of object-oriented programming, and the remaining chapters describing 23 classic patterns. Besides providing time-tested solutions, most of them have something else in common: they employ fine-grained, loose coupling. Although the book is over 15 years old, the recommendations are still applicable today, which is why it remains in the top 20 on Amazon’s top best-selling programing books list.

So, armed with an understanding of MVC and GoF design patterns, all our bases are covered; we have everything we need to develop that robust, flexible, and scalable, enterprise application, right? Sort of. With a lot of care and planning (and I do mean A LOT) we can create an application that lives up to these goals, but the plumbing that links all the business logic together can add a huge amount of infrastructure complexity to a project; and worse: it tends to be tightly coupled to the business components! It would be better if we could just plug our business logic into some existing structure. If you had something like that, you could focus on what a program is supposed to do and not how it’s glued together. And better yet, if it does it using design patterns, our loosely couple business classes will be loosely bound to the infrastructure.

Eureka!

Java Frameworks do just that:

• provide all the plumbing infrastructure
• implement design patterns
• enforce MVC

And they do in a way that is open to most any application development requirements. In my upcoming articles I will take a look at some of the most popular frameworks: Hibernate, Enterprise JavaBeans (EJB 3.0), JavaServer Faces (JSF), Struts, Spring, and others.