So what about the right architecture?
As they say that with large amount of power comes a large amount of responsibility. Seam bundles in a lot of power with the features and functionalities it provides to quickly develop a working application. That said, Seam also gives you the capability of directly invoking the persistencemanager from the XHTML. Does it remind you of the days when developers used to make JDBC calls directly from the JSP pages? This might not be bad for a quick POC or a hobby project but it would certainly not sell in an enterprise.
So how do you define the right architecture for an enterprise seam application?
Most of the enterprises eventually struggle with the following issues if the architecture is brittle.
- Complexity too high
- Leakage of concerns
- Tight coupling between presentation and business layers
- Architecture governance is insufficient and cannot be enforced
- Easy things are not easy, hard things are not possible
- An error in one section of the system can affect the entire site
- Maintenance and Enhancement is a constant challenge
- Reliability and Stability issues.
An architecture should be able to handle these concerns. We decided that in order for a Seam application to ensure that it is still loosely coupled the following architecture based on the standard suntone architecture methodology should work well.
As you would note that there is a clear separation of concern between the layers. Different types of classes for a Seam application may be categorized as follows.
- Action Classes – Presentation logic and User interaction handlers
- The action classes call Service Layer or DAOs which should be injected with @In ,
- Avoid injecting persistence managers here since the presentation layer should not know about the data access logic.
- All @Out declaration here, @Out Objects that should be outjected to its context variable at the end of the invocation.
- The scope of the action classes is EVENT by default.
- Conversations should be started here with @Begin. Actions should know when to @End the conversation and how long the conversation should be. Ideally long running conversations should be avoided.
- All presentation layer logic resides here including the objects which should be exposed as @DataModel, @DataModelSelection etc.
- Service Classes- These classes have the main business logic.
- DAOs might be injected here.
- Transactions should be started here.
- DAOs – Data Access Objects to talk to the resource layer
- Persistence Manager should be injected here.
- All (data) resource access mechanism lies here.
- Annotated Validation rules might be put on the entities. These validations work both for form validation and validation before the persistence happens.
- Entity Objects – Define the domain of the system
- These objects are annotated with @Entity
- They form the domain logic and are persisted.
- Value Objects – These are not defined with the @Entity annotation, but do serve as ‘backing beans’ for the forms. These would not be persisted directly.
As you would also note from the figure that various layers can be unit tested and integration tested separately with ease. Stay tuned for Seam development best practices and how to test the various layers of the Seam application.
Interested to know more about our JBoss Seam capabilities? Get in touch with us on email@example.com