J2EE Architecture Best Practices (Continued)
Another common mistake is putting a lot of presentation-type logic in the model layer. For example, if the JSP page needs the date formatted in a specific way or the data ordered in a specific manner, some would place that logic in the model layer, which is the wrong place for this logic. It should actually be in a set of helper classes the JSP pages use. The Action Bean should forward the data to the view layer as the business layer returns it. This allows flexibility in supporting multiple view layers (JSP, Velocity, XML, and so on) without creating unnecessary coupling between the model and the view. It also allows the view to decide the best way to display the data to the user.
Finally, most MVC applications I've seen have an under-utilized controller. For example, most Struts applications will create a base Action class and perform all security-related functions there. All other Action Beans are derived from this base class. This functionality should be part of the controller because if the security conditions are not met, then the call should never reach the Action Bean (or model) in the first place. Remember, one of the most powerful features of well-designed MVC frameworks is the presence of a robust and extensible controller. You should leverage this power to your advantage.
Lesson 5: Don't Be Embarrassed by POJOs
I have witnessed many projects that use Enterprise JavaBeans for the sake of using Enterprise JavaBeans. Sometimes it's the coolness factor, because EJBs appear to give the project an air of superiority and self-importance. At other times it arises from confusion about the difference between J2EE and EJB. Remember that EJB and J2EE are not synonyms. EJB is only one part of J2EE. J2EE is a set of many technologies, including JSP, servlets, Java Message Service (JMS), Java Database Connectivity (JDBC), JAAS, Java Management Extensions (JMX), and EJBs. J2EE is also a set of guiding principles and patterns on how to use these technologies together to create solutions.
If you use EJBs when they are not required, they can hurt your application's performance. EJBs typically require a more demanding application server than a plain old Web server. They typically consume more memory and CPU time because of all the value-added services they provide. Many applications don't require these services, and the application server consequently competes with the application for resources.
In some cases, unnecessary EJB use can even cause your applications to break. For example, I recently came across an application developed on an open source application server. The business logic was encapsulated in a series of stateful session beans (EJBs). The developers had worked hard to completely disable "passivation" of these beans in the application server. The client wanted the application deployed in a commercial application server that was part of the client's technology stack. This application server did not allow turning passivation off. In fact, the client did not want any changes to its corporate application server settings. As a result, the vendor had a big problem on its hands. The (almost) funny thing is that the vendor couldn't provide a good reason why it even implemented the code as EJBs (and stateful session beans at that). Not only did the vendor suffer from performance problems, but its application did not work at the client site.
Plain Old Java Objects, or POJOs, are powerful alternatives to EJBs in Web applications. They are lightweight and don't carry all the extra baggage associated with EJBs. In my opinion, many EJB benefits such as object pooling are overrated. Don't be embarrassed by POJOs; they are your friends.
Lesson 6: Data Access Does Not Mandate O/R Mapping
All Web applications I have worked with that provided user value accessed data from somewhere and hence required a data access layer. That does not mean all the projects identified and delineated such a layer; it simply means that such a layer existed either implicitly or explicitly. In the case of an implicit data layer, the data layer was part of the business object layer (or business services). This works for small applications, but it goes against generally accepted architecture guidelines for larger projects.
In general, a data access layer must meet or exceed these four criteria:
Business objects can use the data source without knowing the specific details of the data source implementation. Access is transparent because the implementation details are hidden inside the data access layer.
Enables easier migration
A data access layer makes it easier for an application to migrate to a different database implementation. The business objects have no knowledge of the underlying data implementation, so the migration involves changes only to the data access layer. Further, if you're employing a factory strategy, you can provide a concrete factory implementation for each underlying storage implementation. In that case, migrating to a different storage implementation means providing a new factory implementation to the application.
Back to top