Seam Agile Development and Java EE Classic layered architecture __java

Seam Agile Development and Java EE Classic layered architecture

Reprint please retain the author information:
author:88250
blog:http:/blog.csdn.net/dl88250
MSN & Gmail & qq:dl88250@gmail.com

This article briefly discusses two issues: the links and issues between seam and the classic Java EE layered architecture, seam and JSF 2.0 specifications. This is a series of articles that will discuss the problems with the Seam framework for actual development.

Seam Agile Development and Java EE Classic layered architecture

In Seam because of the bidirectional injection (binjection) mechanism, allows us to reduce the level of division, simplifying the design, development complexity. This is also one of the goals of Seam framework. However, due to the characteristics of this project (open source, large scale), I decided to design it based on classic Java EE layering.
Persistent layer DAO
in Seam, you can completely ignore the persistence layer DAO and directly manage the entity in the business logic. The advantage of this is that development can be more convenient and efficient, and the downside is that it is less reusable and difficult to maintain. Especially in this open source project, distributed team collaboration, excellent design allows each developer to better understand the system. Combined with the advantages that Seam provides to us, we decide to provide DAO for common entities. View and component
because a Seam component can be called directly from the view layer using EL, So there will be a component at all levels that can be used in
View. This can lead to confusion, should a façade layer be created to provide the components that the View needs. But doing so will greatly complicate the design of the entire system, especially the rapid development ideas that Seam advocates. The benefit, of course, is that the View developer can use the components provided in the façade layer without having to understand too many logical components.

After a comprehensive analysis, I think the DAO is needed, but the Facade pattern should not be placed in the design based on the Seam framework. The reason is that seam has "glued" the View and logic together, and we should not give up the advantage seam brings us. The interface between View and the business logic implementation is to be defined anyway, and the façade pattern should not be used for convenience. Therefore, the application scene of the façade model needs to be deeply thought and practiced.

two. Seam and JSF 2.0

Currently, the implementation of JSF 2.0 is already available, but Seam still supports JSF 1.2 only. JSF 2.0 enhances AJAX, defaults to using Facelets as the view definition, and a series of new JSF components and modifications. This will have a significant impact on some of the existing JSF implementations (RichFaces, myfaces, etc.). But there's no way to do that, and now that the project is in development, Seam should provide the solution when JSF 2.0 is officially released.