Written by nitinpai on March 30th, 2008
Designing Enterprise Applications – Approaches and Patterns
JavaWorld has published a useful research paper which discusses how to discern which design patterns and frameworks would work best for your enterprise applications, written by Chris Richardson. As a developer it is very essential to know about the different strategies one would adopt in a particular business scenario. This paper helps you in making important decisions about which design patterns would best suite a given set of requirements.
According to the research done by Chris for enterprise applications, here are some of the important points which the paper elaborates:
- Make use of the POJO approach, with lightweight frameworks like Hibernate for ORM and Spring AOP for transactional activities.
- EJB 3 makes it possible to have your business logic sit within your POJO and also make it run outside the container which makes it really usable.
- Implementing 3 tiers for an application which commonly include
- Presentation tier
- Business Interfaces for encapsulation + Business tier logic in classes
- Persistence tier for handling transactions and concurrency
- The design should involve,
- Modeling your business classes appropriately
- Code structuring principles for easier maintenance
While the above points are usually very well known amongst the developer community, it helps if you know which decisions should be taken when. Design patterns which have been established over the years play a key role in making such decisions. The white paper explains a few of the design patterns which are particularly mentioned when enterprise applications are into consideration.
I would like to enumerate here, some of the different design patterns which are highlighted in the paper, according to the decisions which fall into 3 main categories.
Decision #1 – Organizing Business Logic
When you have to implement the business logic it is very important to identify the scope and the scale of the application to decide one or the other approaches as stated below,
Transaction Script Pattern:
- Does not follow the object oriented principles
- Methods are mapped to application request from the presentation tier, which are called as Transaction Scripts
- Follows the procedural approach which makes classes less important and methods more important
- Simple to implement but difficult to understand and maintain the code
- Mainly used when business application is small
Object Oriented Approach:
- Maps the objects from real world to the application
- Easier to understand the application logic
- Behavior and state are encapsulated inside the mapped objects
- Lightweight frameworks help to apply this approach to your application.
Table Module Pattern:
- Involves mapping of database tables to business classes
- An object of a table includes all rows of the table rather than a single object mapped to one row
- It suffers from the problem of maintenance.
Decision #2 – Encapsulating of Business Logic
Well designed Business applications always encapsulate logic from the view. This helps in application scalability and security, at the same time providing loose coupling between the different tiers. The patterns which can be adhered to encapsulate business logic are:
Session Facade Pattern:
- Promotes proper encapsulation of business level logic
- Handles transactional behavior, security and presentation tier requests
- Does caching of objects to prevent memory overloading in case of many requests
- Delegates requests to proper business objects
- Was earlier implemented by using EJB 2 Session Objects
- It is heavy on memory and time consuming for testing and development
POJO Facade Pattern:
- Business logic encapsulated within simple POJO’s
- Easier to develop and test and can run outside the container
- Transactions , security and state can be maintained through AOP
- Spring framework uses this pattern
- Light on memory
- Makes use of Dependency Injection for wiring the business classes instead of using JNDI
Exposed Domain Model Pattern:
- Used to avoid extra code for designing the facade
- Presentation tier can directly access data objects
- Makes use of AOP to access business objects without an intermediate facade layer
- Drawbacks include the requirement of transactions and data handling by presentation tier
- Risky since presentation tier can directly manipulate persistent data.
Decision #3 – Database Access
The decision of accessing data is of strategic importance since IO has a major impact on application performance. So apart from making a decision on the databases and normalization it is crucial to have the best approach for accessing it from other tiers in the application. The paper emphasizes that,
Direct JDBC has drawbacks such as:
- Boiler plate code for handling connection and fetching of data
- Database specific SQL reduces the portability of the application
- Maintenance of low level SQL poses problems from schema changes
- Can be of advantage when vendor specific features have to be accessed
To overcome the disadvantages of JDBC, using a framework like the iBATIS Framework can be advantageous since:
- Direct SQL queries can be used
- Provides mapping between resultsets and Java Beans through XML descriptor
The Advantages that Persistance Frameworks offer are:
- Mapping of data to domain objects
- No need to write SQL code
- Flexibility offered by configuring XML descriptors for domain level objects and data
- Loading & updating of database as and when required
- Transactions and concurrency are handled by the framework
Enterprise applications should be modeled and designed properly from the early phases itself. Without following proper approaches from the ones mentioned above can be an invitation for trouble. I hope that these approaches help the developers to come up with good designs for enterprise applications.