Inversion of Control & the Control Tier
Most UI frameworks employee a standard MVC architecture and mine is no different. The purpose of the control tier is to orchestrate the flow of control through the application logic tier and the presentation tier, ensuring that the data from the logic tier is available in a clean way to the presentation tier. You'll remember that one of my design objectives was to ensure the physical isolation of each tier of the application.

Technically that means that I should not reference any class or library specific to another tier in a given tier. Instead, there should be well defined contracts that are enforced at the boundaries between the tiers, allowing them to communicate with one another. These contracts are expressed as interfaces containing well-defined API's and the various tiers merely reference the interfaces. The implementations of these interfaces remain hidden thanks to Spring.

Back in the day, architects made heavy use of the Singleton and/or Factory patterns to gain access to an implementation of an interface. Today, most enterprise applications make use of an Inversion of Control container to instantiate the concrete implementations of these interfaces and then inject these instances into the classes that need them using the dependency injection pattern.

The main servlet of the application, part of the Spring presentation framework, receives requests forwarded from Tomcat and dispatches the request based on the path contained in the URI to a standard Java class, called an Action plain old Java Bean or Action Bean. The URL parameters, whether get or post, are forwarded along to the class and used to initialize the members of the Action Bean.

The Action Bean does not contain any business logic. Its purpose is to merely fulfill requests made from the browser. Spring injects the Application API object into the Action Beans.

Application Logic Tier
The Application API is an interface whose concrete implementation is injected into the Action Bean classes so they can access the business logic of the application. The Application API is itself nothing more than a wrapper around the various services exposed by the application. I have a site service for authentication and session management and such. I have a photo service for the photo application I wrote to manage my family photo's. I have a blog service for the blog software I wrote from scratch. I have a post office service, a file system service and others. These services are injected by Spring into the Application API and then I use the Facade Design Pattern to bring all the service interfaces into a single consistent API for the Action Beans to use. Each Service is comprised of the logic specific to what that service does. Note that the services themselves still do not directly access the database.

Model / Persistence Tier
Spring injects a Data Access Object (DAO) interface into the Application Services of the Application Logic tier. These DAO's provide API's that take and return standard Java classes that are eventually persisted to/from the database. The Application Service methods then contain logic and method calls into the DAO API's. This not only free's the application logic developer from having to think about SQL but also about transaction management. I use Spring declarative XML configuration to specify the Services that should have transaction management applied. So, if an exception occurs at any time during the execution of a single Service API method, Spring will cause a rollback to occur for whatever database operations were invoked as a result of calls to the DAO API's. As a result, the application programmer spends her time thinking about the logic and not the details of databases. Also, the actual database in use is irrelevant since its details are completely abstracted from the application, as it should be.

The concrete DAO implementations themselves are powered by iBatis which performs the actual mapping between Java classes and database queries.

UI / Presentation Tier
Once the Action Beans have triggered the right business logic by calling into the Application API and thus have whatever data is required to fulfill the request, the Action Bean forwards the request to one of a few Freemarker page templates. External XML configuration determines which page template to choose based on the URL of the request and other state set on the Action Bean. There are page templates for the various levels of pages in the website as well as Ajax templates, RSS blog templates and so forth. The actual content specific to the request is embedded in the page template via a generic Freemarker invocation to a call to the Action Bean's ID method. The content template is then loaded that matches this ID.

The Freemarker content template contains very little HTML and mostly Freemarker components representing forms, form fields, dynamic actions, etc. If you haven't yet used a component-based UI framework you really should give it a shot. You'll really learn what code re-use really means. For example, I've got a blog entry component that has a few different rendering facets. I am able to use this same blog entry component for the home page of my site, for the entry-specific page, for the blog entry creation/update page and all by embedding a single component in each of these page content templates.