The Need for Separation, Part 1

In the first article in a series, dealing with MVC separation using the Java Platform, Enterprise Edition, we will explore available technologies in Java EE. Then, we will see how using them without structure causes immense problems in the exact type of application Java EE was built for: big ones!

The Problem

Core technologies for presenting dynamic web pages in Java EE are Servlets and JSP (Java Server Pages). For the sake of this article, I will assume familiarity with both technologies. Two organization structures of these technologies is naturally apparent.

Straight JSP

The first approach in the context of a large application is to manage a number of jsp pages, which make use of java beans and scriptlet code to make calls to java classes in the main portion of the application. These types of calls and code will be sprinkled throughout the jsp, whose predominant purpose is to put together the html response to a client request. As mentioned before, this is in the context of a large web application. When dealing with a simple, small, and relatively static web application, this organization structure is easy to use, and typically doesn't present a large maintainability problem. As soon as the application grows beyond a few pages, it becomes largely difficult to keep this sprinkled logic mixed with html organized. If you analyze an application built this way, you should also immediately be aware of the poor form and design of the application. Also, the urls in the application are strongly tied to the file organization, which is a particular problem for the purposes of search engine optimization.

Servlet Controllers

Since jsp is simply a page that is compiled into a servlet, saving the programmer the hassle of managing html through println() calls, the second obvious approach is to use servlets to perform these calls to the main portion of the application (where the "business logic" lies). Once the calls to the business tier of the application is complete, the programmer can pass some variables to a jsp "view" using the request object provided by the servlet container. This is a decidedly better organization for an application, because you no longer have the unwieldy mix of logic and presentation code. This practice of separating presentation from logic is a common and well understood practice by many programmers. The use of templating engines in several scripting languages like php is testament to the popularity of this approach. In fact, the modern version of jsp was created for just such an approach, and would explain the ability for a servlet to forward control to a jsp page.

The problem with this second approach is not obvious until the front end (the web tier) is being built. Each servlet needs a url mapping in an xml file before it can be used to serve responses to client requests. This presents several technical challenges. First, while the mapping capability means that urls can be freely formatted and remain unrelated to the underlying file structure, the maintenance of these urls is not particularly desirable, as not just url patterns (groups of urls) need to be maintained, but every url in the entire application. What's worse, each url mapping needs a corresponding servlet mapping, so the url can map to a servlet, and the servlet can map to a physical java class.

The Solution

The popularity of MVC frameworks is testament to the success of stacking a little bit (or a lot) of code on top of a language to provide automated functionality. No matter your disposition on frameworks, some sort of magical functionality needs to take place in order for the manual process of mapping urls to resources to go away. Unfortunately, this magical functionality is one step farther than the Java EE specifications have gone. It's easy to see why it would be ineffective to provide this at the api level. The Java EE specifications already provide (or specify how an app server should provide) a world of automatic functionality in the form of containers, factories, persistence management, etc. To force a given organization on the code would be to destroy the power of the programming language itself, and ruin the chances of innovation for future generations of programmers.

Next article: The Front Controller.