J2EE Design Patterns

Architectural Antipatterns

The first class of antipatterns we will look at is architectural in nature. These antipatterns are not J2EE-specific: they affect many Java applications and the Java APIs themselves. They are included in a book on J2EE because they affect highly scalable, long-running applications—meaning they are of particular relevance to J2EE developers.

Excessive Layering

If you’ve read the preceding chapters, you’ve probably noticed that design patterns tend to suggest adding layers . Façades, caches, controllers, and commands all add flexibility and even improve performance, but also require more layers.

Figure 12-1 shows a rough sketch of the “typical” J2EE application. Even in this simplified view, each request requires processing by at least seven different layers. And this picture doesn’t even show the details of each individual layer, which may themselves contain multiple objects.

Figure 12-1. A standard J2EE application

Unfortunately, in a high-level, object-oriented environment like J2EE, the layers we add are not the only layers that exist. We’ve already talked about containers—the servlet and EJB containers are the main ones—and how they provide advanced services, generally through layers of their own. The underlying containers are themselves built on top of Java’s APIs; the APIs are still a few layers away from the JVM, which interact through layered system libraries ...