Tim Hengst wrote:
> Peter Bishop wrote:
>
> Of course, I would also encourage you not to put Java code in your JSP pages
> in the
> first place (beans and servlets are a better approach, IMHO) ... but that's
> a
> different issue.
>
> Can this become a discussion topic? What are the advantages/disadvantages
> of keeping the Java code encapsulated in beans and servlets?
>
The biggest disadvantage is increased complexity -- although this is not as
significant on a large application -- especially as you are first setting the app
up. Everything else is an advantage.
In my experience, the most important issue for long-term maintainability of a web
based application is to separate the presentation logic ("how does this application
look and feel to a user?") from the business logic ("what does this application
actually do?"). What tends to happen over time is that things change:
* You do a web site remodel to refresh the look and feel
* You add a new database back end to increase capacity
* You switch from JavaBeans for business stuff to EJBs
* You suddenly face the need to integrate a bunch of XML-formatted
data into your environment
* You have to adapt to a distributed application server because
your app has become popular and business-critical
and what you are after is minimizing the impacts of those changes. When you have
things appropriately separated, you can do things like a web site remodel with
little or no impact on the underlying business logic. Likewise, you can
fundamentally change how the back end functions operate -- but as long as they are
hidden behind JavaBeans the provide access to the required information, the web
pages themselves need to change very little. These kinds of changes are *much*
more difficult to make if everything is all mixed together.
Other advantages to separation are also of interest:
* You are not stuck doing everything on one server -- if need be,
you can put the presentation stuff on one box and the business stuff
on another -- with the database on a third, if appropriate -- and scale
each tier individually to meet changing demands.
* Mixing presentation and business logic means you need someone
reasonably good at both HTML and Java to create your app. Have
you had much luck finding people that are good at both those things?
* Separating presentation logic and business logic means you can
leverage the skills of page designers and Java developers separately --
people who may not be good at, or actively dislike, the other discipline.
It also allows each group to utilize tools focused on their particular
technologies, without having to worry much about the other side.
* Application architectures and designs based on a strict separation
of concerns tend to be technically better, with clearly articulated
interfaces between the layers.
The same basic issues were evident when people started building complex
client-server GUI based applications. The solutions then were pretty much the same
-- and popular web application frameworks (like Struts) have even adopted the
Model-View-Controller (MVC) paradigm that was first popularized in such application
designs.
None of this matters very much if you are writing a simple "guest book" type of
application. These things matter a *lot* if you're designing an Amazon.com type
application system. Even if you think your app is currently closer to the "guest
book" level of complexity, where is it likely to be in a year or two? That is what
you should architect for now. Because, once the basic architecture is in place, it
is *very* difficult to change later.
>
> Tim Hengst
> Tampa
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
