Popular antipatterns

At a recent training session I debated the Data Transfer Object design pattern. It effectively decouples layers of an application. A classic example is the view and the application's business logic. DTOs reduce coupling between those layers. Another good example is the View Helper, which mediates between the communication protocol and business logic.

Why talk about these patterns in particular? Developers tend to forget them. Ask yourself how many of your applications used DTOs instead of passing domain objects around that doubled as persistent entities. I suspect there were few, if any. Your application's architecture may lack clean separation, but it does its job well enough.

The basic idea of Seam is to expose EJB beans as managed beans for JSF. This approach even became the basis of JSR 299: Web Beans. In other words, the application's business logic is the view helper, so you do not need to write that intermediary. It is tempting to avoid the extra code, but at what cost?

Once again, our application's architecture will lack clean separation. In this case it has implications, since the business logic has to be aware of the arrangement through annotations and the programming model. Still, it is possible to live with it.

For a long time, I felt that enterprise design patterns were simply part of Java and that everyone choosing Java accepted them. In exchange, you had a good chance of ending up with something you could extend instead of a one-off patchwork. Lately it looks to me as though Java is leaving that architectural discipline behind.

The first reason is probably the rise of frameworks such as Ruby on Rails. Being able to build something so easily is hard to resist. Of course, that simplicity comes at a cost to the application's architecture. A second reason may be that most developers do not need what enterprise patterns offer. For example, they see little benefit in rigorously separating the view layer from business logic.

This makes me wonder whether Java will really head toward rapid application development. The danger is that getting something working somehow, and fast, comes first, which carries the risk of a messy architecture. That is essentially the PHP model, which works well in the short term but has proved unsuccessful in the long run.