Need:

Current Implementation
Currently transactions are managed at the level of Struts actions, or by explicitly calling transaction management methods on the HibernateUtils class at various layers of the application (including domain business objects and Persistence classes).

Proposed Improvements:

Implement cleanly separated layers for:

• Presentation
• Service
• Repository (Data Access Object)
• Domain (Business Object)

The presentation layer would initially contain just web GUI related code. This would include input processing and page flow management, but no transaction code. It also implies eliminated business logic and moving it to the business objects themselves or the service layer as appropriate.

The service layer would encapsulate high level business operations and transaction management. The service layer would be called from the presentation layer to execute business operations. Moving this functionality and the associated transaction management to a service layer would allow multiple presentation layers (including mobile phones or web services) to make use of the same underlying code.

The repository (or data access object) layer would encapsulate all CRUD (create, read, update and delete) operations for business objects. Included in the "read" aspect of this layer is the encapsulation of queries to retrieve objects of the type managed by a given repository. There would be no transaction management code in the repository layer. This layer is closely related to the current Persistence classes. However Persistence classes currently include some transaction management.

The domain layer would consist of business objects implemented as Plain Old Java Objects (POJOs). This implies that no transaction related code would be present in this layer.

Anticipated Benefits

1. Clearly defined layers should make it easier for new developers to know how new functionality should be developed by following guidelines for which layer is the right place to implement a given kind of functionality.
2. A clean service layer would set the stage for implementing different presentation layers (such as a mobile platform, or web service layer).
3. A clean service layer would provide a good place to implement security that is decoupled from the web GUI and could be common to all presentation layers.
4. A Repository (or DAO) layer defined using interfaces would allow for a given repository to be replaced by an in memory implementation and provide a way to start reducing the time for running the test suite.
5. Moving transaction related code out of the business objects would allow unit tests to be written that do not have database dependencies and help to reduce the time required to run the test suite.

Suggestions: