Java Reference
In-Depth Information
from putting too much into the View portion of the
architecture. Practices like using JSP tag libraries to perform
database access, or performing application flow control
within a JSP are relatively common in small-scale
applications, but these can cause issues in later development
as JSPs become progressively more difficult to maintain and
debug.
Likewise, we often see migration of View layer constructs
into business logic. For instance, a common problem is to
push XML parsing technologies used in the construction of
views into the business layer. The business layer should
operate on business objects and not on a particular data
representation tied to the view.
However, just having the proper components does not make
your application properly layered. It is quite common to find
applications that have all three of servlets, JSPs, and EJB
components, where the majority of the business logic is done
in the servlet layer, or where application navigation is handled
in the JSP. You must be rigorous about code review and
refactoring to ensure that business logic is handled in the
Model layer only, that application navigation is solely the
province of the Controller layer, and that your Views are
simply
concerned
with
rendering
model
objects
into
appropriate HTML and Javascript.
Just a few years ago, user interface developers for Web
applications could choose from servlets and JSPs, struts, and
perhaps XML/XSL transformation. Since then, Tiles and
Faces have become popular, and now AJAX is gaining a
strong following. It would be a shame to have to redevelop an
