JSP Coding Methodologies

JavaServer Pages is a great way to create dynamic Web sites and applications. Just like any other programming language, it is good to have a working methodology for creating your applications. This sample chapter introduces you to coding methodologies using JSP, including how to use the Model-View-Controller (MVC) method using only JSP pages.

This chapter is from the book

This chapter is from the book

In this article, you are going to look at the code you write from a very high
level. Here we discuss how you decide to write your code before you begin
writing it. This is probably the single most important decision you will make
because what you decide will become the foundation upon which all future
upgrades and additions to your application will be built upon.

There are two general approaches you can take when developing applications.
Within each approach, you can establish your own specific methods for dealing
with programming issues. I refer to these two approaches simply as the
Page-centric and Program-centric architectures.

Page-centric Architecture

Page-centric architecture is probably the most common methodology for
developing dynamic Web applications. This architecture focuses primarily on
creating JSP templates. These templates are generally divided up by a logical
directory structure, with multiple JSP pages in each directory. Each JSP page
performs a specific functionviewing database information, processing
email, storing shopping cart information, and so on. Figure 1 shows how this
model works.

This is a fairly common approach, and is the one used most by ColdFusion, PHP
and Active Server Pages (ASP) developers.

There are a number of advantages to this approach:

SimplicityCreating an application within this environment
can be done with ease. A basic understanding of JSP is all that is needed to add
or edit the application.

HomogeneityEverything in this application will be a JSP page
of some kind. There may be some instances where a JavaBeans component or custom
action is utilized, but the majority of changes can be made by directly editing
a JSP template.

Time-to-MarketJSP-only applications can generally be built
faster in the beginning because there are fewer elements involved.

AccessibilityBecause JSP is fairly easy to develop,
especially with tools such as UltraDev and JRun Studio, even designers can
participate in dynamic development. This means that it is not always necessary
to have a Java programmer or team of programmers to make functional additions or
changes to an application.

The overall compelling reason for using this approach is that it is fairly
simple, and doesn't require a deep knowledge of programming or a team of
developers. While this is a truly viable coding approach for many projects, this
design has somewhat of a bad reputation among hardcore Java programmers due to
its weaknesses.

Using the Page-centric approach is also more intuitive to understand from a
browser's perspective. Each page has a function, and there is a clear
connection between a page and the type of information it contains or the
functionality it will deliver. For example, a page called
EnterMovie.jsp will serve the function of entering new moviesthis
is easy to understand.

However, taking this approach has its disadvantages. The main problem is that
as a Page-centric application evolves over time, the code can become convoluted
as different programmers make their logic changes directly in the JSP page.
These pages can become overwhelmed with scriptlets as core business logic
becomes embedded in every page. Ultimately, a Page-centric application must be
managed carefully, or it can become a behemoth requiring a complete overhaul to
add any new functionality.