JSP pages as controllers have the advantage of being "re-compiled" during
development, so any changes you make are immediately picked up on the next
access to the jsp page, without having to recompile, restart the server,
etc. However, Orion app server and Resin Servlet engine both allow you to
"reload" a class that is modified using a development mode setting.
Frankly, as the writer of a MVC framework called Theseus, I wouldn't want
to use JSP as the controller over a MVC framework that uses a single
controller servlet, action classes, xml config files, and so on. I can
rapidly build web apps with Theseus, as can be done with Struts as well.
Probably this makes sense if you want to use MVC development, but want a
"fast" way to quickly prototype a servlet as the controller. I don't think,
in the end, it makes much difference, except that the servlet engine
produces the final servlet output that the JSP page is compiled in to,
where as when writing the controller, or using a framework (which gives the
source, like Theseus and Struts) you can control the actual servlet code a
bit more.
How I develop seems to me to make the most sense. I use Theseus which calls
upon action classes to do the "controlling" work (an extension of the
Controller Servlet). In the action class, each method would call upon EJB
to do the business logic. You could "prototype" by putting business logic
right into the action class methods, but then your tying your business
logic to the web-tier. This may be ok for your needs, but it will hamper
scalability a bit. By breaking business logic into EJBs (stateless), you
gain a few benefits. First, you can "scale" your business tier as needed to
handle clients other than the web-tier clients, such as java clients
running on desktops that directly access the business EJB tier (not
requiring the web tier to do so). You also separate your business logic in
your source, so if you have a team, you can better organize projects into
tier development, which would allow web-tier developers to focus on web
specific stuff (like wireless pages, jsp pages for web browsers, etc), and
the bussiness developers can handle the code for business needs.
Hope that helps.
At 03:56 PM 9/26/2001 -0700, you wrote:
>I'm trying to learn more about MVC, and am reading various sources, but am
>curious to know more about using JSP pages in the role of Controller. Most
>articles seem to suggest that servlets typically are used as the Controller,
>but as one article says, many developers are "coming to realize the
>advantage of using a JSP page in the Controller role." So, can anyone
>elaborate on when this makes sense? What guidelines would you offer to
>decide where to handle the business logic? Where do you draw the line?
>
>Thanks,
>Steve
>
>===========================================================================
>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
===========================================================================
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
