Using an MVC Pattern Across the Web
How does a model like MVC scale up to the Web? There are key differences to consider. The Web is stateless, which complicates the ability of model objects to stay synchronized with all the views (HTML pages) that have been generated based on the data model. Also, the number of distributed views and controllers interacting with the data model can be orders of magnitude larger than in stand-alone, rich-client GUI applications. Separating presentation logic from the data model is just as important for Web applications as it is for any other type of software system, but bringing the MVC model to the Web presents unique challenges that require careful consideration and planning.
In many ways, effective separation of concerns is even more important for Web projects than it is for other types of software development. A Web application's UI is often developed by a team of graphic artists who have little or no knowledge of Java coding and syntax, rather than by a team of professional software engineers, as might be the case for a rich-client GUI. If the work is broken up along clearly defined interfaces so that each team can focus on its core competency, the project will be completed much more quickly. By effectively separating concerns early in the development cycle, project managers can ensure that programmers stay focused on programming, and designers on design.
Separation of concerns was the major driving force behind the development of JSP technology. Most HTML page content available on the Web is actually a combination of "static" template HTML markup along with dynamically generated information that is retrieved and/or updated anew with each and every HTTP request. JSP was devised as a means to separate the Web content (much of which could originate in back-end databases) from the way it's presented to the user (e.g., HTML code).
JSPs resemble HTML pages, except they contain embedded segments of Java code. They are a presentation-centric, declarative way of binding dynamic content with application logic. Because they run inside a Web server and are compiled into servlets prior to execution, JSPs are capable of invoking a range of server-side functionality, including transaction support, database access, state maintenance, security, distribution, and load balancing. However, system architects may want to carefully weigh the costs and benefits of invoking particular types of behavior—particularly database access—directly from a JSP page, rather than using some type of middle-tier abstraction layer.
 [click for larger image] A JSP is responsible for both controller and view responsibilities. The data model is encapsulated inside the Enterprise JavaBean (EJB). |
JSPs are a more user-friendly way of managing presentation code than are servlets.
Servlets are a programmatic tool and are best suited for low-level application
functions that don't require frequent modification. Ultimately, however, JSPs
are compiled into servlets and run on the Web server itself. The Java code embedded
into the (original) JSP page is compiled "as is" into the resulting
servlet. The HTML markup portion of the JSP page is compiled into a series of
out.println() statements in the resulting servlet, saving developers the time
of manually typing in mindless lines of out.println() statements and allowing
graphic design teams to work directly on the template layout in HTML. See the
Listing for an example HelloWorld.jsp page.
How does JSP technology relate to the MVC model? So far, it doesn't! What I've been describing is known in the JSP specification as a Model 1 architecture (see graphic). In a Model 1 system, the JSP page alone is responsible for processing the incoming request and replying to the client. The data model is usually represented by an entity Enterprise JavaBean (EJB), or possibly by a session EJB that is acting as a façade for an entity EJB. Model 1 succeeds in separating content from presentation, but can result in a significant amount of Java code being added to JSPs. This in turn can slow down a large project if the JSPs are being created and maintained by a team of graphic designers, as is often the case. Moreover, in Model 1, JSPs are statically linked to one another. This makes Web application functionality less reusable, and can complicate adding and modifying client types, data views, and workflow. Each JSP page is also individually responsible for managing application state and verifying client authentication and security.
