J2EE Design patterns Part 1

Any enterprise application is divided into tiers

1- Client presentation tier.

2- Server-side presentation tier.

3- Server-side business logic tier.

4- Sever-side domain model.

5- Enterprise integration tier.

The first three tiers are defined in java by sun, but you can the last two tiers according to your application.

The client presentation tier is the user interface for the end user, the client can be either thin of fat client. This tier can be implemented using HTML and JavaScript.

As you noticed presentation tier are divided into two tiers, the server-side and client presentation tier. The server-side presentation tier is responsible to provide client presentation tier with materials to be shown to end user. The server-side presentation tier can be Servlets and JSPs.

While considering the verbs of the system (e.g. purchase, remove, ….,etc ), you have to mention the server-side business logic tier. It handles the business logic of the system.

The extra two tier are server-side domain model which handles all the models used by the business logic. In this tier we consider nouns in system (e.g. Order, Customer, ….,etc ). The final tier is the enterprise integration tier which handle connection between your system and other systems (e.g. web services, CORBA,…. , etc ).

When evaluating the end product of any enterprise development project, we can score it on four factors: Extensibility, Scalability, Reliability, and Timeliness. Using design patterns increases the score of the project.

Patterns will be divided according to the mentioned tiers, starting with presentation tier where most of the changes occurs. These patterns make presentation tier more extensible

A- Model-View-Controller Pattern.

Dividing the application to javaBeans and jsp and servlets. JavaBeans will show the data from the business logic to view. JSP will view the data. Servlet for navigations between views.

We have two models in MVC pattern , the first model is making a controller (servlet) for each view but it`s not the best practice, because if you need to add a logging mechanism it will cost you time and effort to handle it in all controllers. The second approach is making one controller to dispatch the requests to each service, also this approach isn`t the best practice because if you want to add new feature you will need to retest and redeploy,…etc.

B- Front Controller pattern.

Front controller merges MVC models, by using one front controller that perform the common functions and delegate other specific functions to a page-specific controller. Front controller is also responsible of redirecting to pages. The page specific controller can be Servlets or simple classes that is based on the GOF command pattern. Good example is the Actions in the Struts framework, classes that have common parent class and each class perform page specific functionalities. In the front controller you can add common functionalities so that you won`t have duplicate functions in page specific controllers. Adding common functionalities in front control can be applied using the GOF decorator pattern so that you can extent functionalities dynamically.