Web Tier Design Goals

Web Tier Design Goals
Naïve approaches toward J2EE web tier implementation typically result in JSP pages containing excessive
amounts of Java scriptlets, with a confused mixture of presentation and business logic. The result is an
untestable presentation layer, refactoring headaches, and maintenance hell. Many, if not most, J2EE web
developers have either implemented such applications themselves, when less experienced, or inherited
such code for maintenance and enhancement, cursing the original developers.
This naive JSP-centric programming model owes its origins to ASP and PHP, two popular web programming
environments since 1996. In both, page-centric scripting is the only option, with no easy options
for separating workflow control and view rendering or delegating to business logic components. While
both have advanced since, to ASP.NET and PHP4, respectively, and both now offer better options for
application architecture, the classic programming model unfortunately remains very influential.
There has been consensus in the J2EE community for several years that the web tier in a layered J2EE
application should be better structured than such scripted pages, to offer comparable levels of maintainability,
testability, and reusability as middle tier components. Expert One-on-One J2EE Design and
Development clearly summarizes the central goals for a maintainable and extensible web tier:

❑ A clean web tier separates control flow and the invocation of business objects (handled by Java
controller objects) from presentation (handled by view components such as JSP pages).
❑ The web tier should be as thin as possible: That is, contain no more Java code than is necessary
to initiate business processing from user actions, and display the results. It should contain only
web-specific control logic, not business logic.
The first goal is typically achieved by applying the MVC approach, dividing the web tier into three
kinds of objects:
❑ Controller objects that accept user input and invoke business logic to create and update model
objects
❑ Model objects, providing the data to display, representing the contract between controller
and view
❑ View objects that display model data, as provided by the controller that invoked it

 

In classic desktop GUI frameworks like Swing, the model pushes updates to registered views. For web
applications, a special variant of MVC applies, due to the fact that web applications are bound to a
request/response cycle that does not allow for dynamic display updates: A controller exposes a model to
the view, the model being specifically prepared for the current request, and the view pulls data from its
model as necessary during rendering.
The second goal (a thin web tier) is often less emphasized than the first, as many web frameworks do not
help to separate web control logic from business logic. This is potentially costly, as lack of separation
between web control logic and business logic can compromise several architectural tiers and lead to
what could be called web-only applications: web applications lacking a reusable business layer. In such
applications, the web controller does not delegate to appropriate reusable business objects but implements
both workflow and business logic itself. While this may be adequate for small applications, it typically
leads to code duplication for similar actions, does not allow for easy testing of business logic, and
prevents reuse of the same business logic in other environments.