Best Practice: A J2EE Blue-Print for a Typical Web App
Consider a typical synchronous Struts-based Web application which does a simple DB search and post. What are some of the main patterns and components that should be used if following the 搃ndustry best practices?br>
Does the following flow seem accurate?
Strust Action creates aTransferObject, and passes it to aBusiness Delegate. Delegate finds the appropriateBusinessObject, the Business Object uses theData Access Object?the CRUD operation happens and the result is sent back to the Action in the same TransferObject.
Which one of these components need an interface?
What's the best way for this components to interact with each other (factory, etc.)?
Message was edited by:
kmkiani
Message was edited by:
kmkiani
[813 byte] By [
kmkiania] at [2007-11-26 20:08:16]
# 1
It is nice for the BusinessDelegate to be implemented with an interface class and a concrete implementation class.
TransferObject creation is not typically neccessary from the Action class. Usually, the method signatures of the BusinessDelegate are designed in a way to get String-based data or primitives. The Action class gets the reference for the BusinessDelegate from the session and calls the appropriate method. The BusinessDelegate calls the appropriate method on the BusinessObject and then returns a TransferObject to the Action class.
It is nice to implement the TransferObject with some implementation class from the Collections Framework.
# 3
There are 3 tiers in a Java EE application. (Presentation, Business, Integration).
The BusinessDelegate in this scenario would be a Presentation-tier business delegate. This guy would interact with a Session Facade who lives on the Business-tier. The SessionFacade is the abstraction on the Business-tier and the Business Delegate is the abstraction on the Presentation-tier. It is these guys that have direct communication. This design enables low coupling between the actual implementations of each area. If done properly, you could go from EJB to Web Service to POJO business models without ever having to change anything in the Presentation-tier.
These object-oriented design patterns are primarily for Enterprise applications with extensive Quality-of-Service requirements.
In your scenario, the Presentation-tier would contain a MVC-based web application, i.e. Struts. The business model and business/domain requirements would be implemented in the Business-tier.
Presentation Tier - Struts Web Application
Business Tier - (EJB | POJO | WEB SERVICES) Application
Integration Tier - (Relational Database | File System | XML Database | EIS)
