TapeStry Spring Hibernate integration work summary
Cyberwing
BNUSUNNY@yahoo.com
Franksoo is my project manager. Summary Time The company decided to make a new J2EE secondary development platform to replace the original development platform. The company allows Franksoo and I form a platform development project group, Frankso is the project manager. Now this platform integrated development phase has ended, and enter the project application phase. Below is our integrated work summary, introduce the issues we have encountered in our work and our choice.
1, the selection of architecture
First, we agree that we have no enough time and resources to develop a complete platform with our existing capabilities. Several excellent projects are selected in the existing open source projects to complete the project on time and meet the purpose of the project.
But before the platform project begins, we have their own ideas for the technical architecture of the platform. Franksoo's original idea is Struts Spring Hibernate, and my idea is Tapestry Hibernate.
However, Franksoo is very open, demonstrates Tapestry's classic example Workbench, introduces TapeStry to component-based programming methods, and he agreed to use TapeStry as a framework for implementing the web display layer. I think Franksoo's previous Struts development experience is one of the factors he makes this decision.
FrankSoo gave me a nice introduction of Spring Framework. Wow, what an amazing framework! IOC, Declarative Transaction Support, Hibernate Session Management, Hibernate DAO Support ... These features are just what we need for a middle tire container.
As for Hibernate, this most successful open source ORM project, we all voted a ticket ^ _ ^
Finally we determine the platform's technical architecture is Tapestry Spring Hibernate.
2, architecture integration
The initial platform architecture draws on an architecture mentioned in how to integrate Tapestry and Spring articles [1]:
The Web layer TapeStry is responsible for data input output, responding to user events, and entering the work of the check, by accessing the preloaded WebApplicationContext (provided by Spring, containing all service beans) to get the service bean for the service layer to delegate the business operation they.
The bean of the Service layer is responsible for the USE CASE logic, Domain-related logic entrustments to the bean in Domain Model. Service completes the persistence of Domain Model via DAO. Service is responsible for database transactions and Hibernate session management (declaration through Spring) Transaction Management and Integrated Hibernate Session Management). Another important job of the Service layer is permissions and access control.
Domain Model is responsible for representing the data and Domain Logic. DAO uses Hibernate persistent data and query.
Such an architecture advantage is obvious, the level is clear, the responsibilities of each layer are also clear, facilitating the hierarchical design and development, combined with MOCK and Spring IOC, and Unit Test is also very easy. And the code of the back office, Domain Model and Dao The API does not rely on the web container or the EJB container, the portability is very good, the same code can be used in the web app can also be used in a normal Java App, just replace the UI layer.
According to this integrated architecture, we implemented a simple example that implements list paging query and display, data adds and derested, based on Hibernate Criteria Query provides a relatively universal query mechanism. With MiddleGen and Velocity we can automatically generate Hibernate mapping files, entity classes, and DAO from the already built database table structure, which reduces great workload. We also have a pressure test on this small example (the amount of data in the test is 10,000 records), and it is determined that the platform does not have performance issues. Through this example, we will pass through the entire architecture, and summarize the development processes applicable to use this architecture and need to do.
3, troubled our questions
In the implementation example and the current project application process, we found a number of headaches, some solved, some have not yet.
Question 1: Do you want to use DTO?
In the above architecture, we did not clarify how the service and Web layers were processed. We will discuss it for a long time, don't use DTO, and finally is not available.
Two main reasons for using DTO: 1, reduce the method call between the Web layer and the service layer, pass the data required by the Web to the web through a method call. 2, isolating the Domain Model and the Web layer.
The first reason is not established under our architecture. Because our architecture is centralized, Web and Service are in the same JVM, and the method call between them is not a huge consumption of EJB remote access.
The second reason is to consider. If you allow the object in Domain Model to pass to the Web layer, modify the Domain Model will affect the web layer. If you use DTO, then Domain Model implements changes will not affect the web. However, a large number of changes are not Domain Model implementation changes, but a change in the Domain Model interface, such as a Domain Model adds an attribute, and this property requires user modification, then this time must be modified, no matter whether it is Use DTO. And using DTO, you need to maintain a large bunch of objects, or their builder, which is very boring, and it is easy to go wrong.
Based on these considerations, we didn't use DTO, but to choose Domain Model directly to the web layer. Here is the modified architecture map (huh, modified the figure [2]).
Question 2: Entity Like Domain Model Or Rich Domain Model?
Because we use MiddleGen to automatically generate Hibernate mapping files, Entity classes, and DAO classes, we have encountered a question: Does our Domain Model do not include Domain logic? If you include a business method, how to combine with the automatic generation tool?
After we discuss, we think that a Rich Domain Model is still necessary, which can reduce the repetition code in the service to improve the reuse.
How to combine automatically? use
Tags, generate abstract base classes, we inherit these automatic generated base classes, add business methods.
Question 3: Model Driven Or Data Driven?
The way Model Driven is also Data Driven. Everyone has a warm discussion. We are mainly affected by Rod Johnson [3], which uses Data Driven's way. Before you do a database design, generate a library table, then generate the Hibernate mapping file and Entity and DAO with MiddleGen. But we have two questions after entering the project application: a) Database design only illustrates the static data to be managed by the system, we still have object-oriented analysis to reflect the dynamic behavior of the system. Especially when the system's business is not just a simple CRUD operation, this problem is more serious.
b) Database design In order to optimize performance, several data should be put into an entity in a single entity. This is simply unacceptable if it is directly reported to the Entity class. Object-oriented analysis design models are quite fine. This situation also has to be object-oriented analysis, which is clear that the big table of the coarse particle size should be mapped into the fine-grained object.
Perhaps we should try Model Driven, generate Domain Model, Hibernate Dao, Hibernate Mapping, database table, simple service, and TapeStry pages in the front desk with AndroMDA.
Question 4: How does the Hibernate session life cycle management?
For the lifecycle of Hibernate Session, we use the session-per-transaction mode, which is not used in Open Session in View mode. Although Hibernate Team thinks that this method is not bad, and atlassian's Conflunce and Freeroller use Open session in view modes, we have no well-grasp of the impact on it, so it is not necessary to discard it. If the Web layer is to access the data of Lazy Load, you need to call the service's business method to get the data.
Question 5: How is USE Case Logic and Domain Logic?
Service is responsible for USE Case Logic, Domain Model is responsible for Domain Logic. Such division looks very good, it is very troublesome. How to divide what is use case logic, what is Domain logic? TBD.
Question 6: How does the service level determine?
This problem is really annoying, just considering the use of Usecase Controller, each Usecase corresponds to a service, but it is found that there is too low, and many places must be multiplexed: (
Another way is to use Package Level Service, each package is a service, which is reused, but it feels too dead, not good.
There is no good way now, I have to determine how many services needed according to the specific situation during detailed design. TBD.
Question 7: How to set the permissions? How to check?
Permissions settings are also a headache problem. We want to set permissions according to USE CASE, each use case. Direct processing directly in the role settings is a very clear permission. However, issues were found during the permission verification: If verify permissions in the service method, and this method is used in the case (multiplex service), then this service method needs to check multiple permissions, if each service method Corresponding to one permission, the permissions are too thin, not like the USE case authority, representing a complete business. It is really trouble! TBD.OK, these are the results of our work. I hope to give you some inspiration, I hope to get everyone's help, help us get an idea, thank you.
REFERENCE:
[1] Integrating Tapestry and Spring Framework. There is a separate article on the Spring website, now in Spring Reference, see Spring Reference, Chapter 12, Section 7.
[2] Wiring Your Web Application With Open Source Java, Mark Eagle, 2004/04/07, O'Reilly onjava.com, http://www.onjava.com/pub/a/onjava/2004/04/07/07 WiringWebapps.html.
[3] EXPERT One-ON-One J2EE Design and Development, Rod Johnson, 2003, Wrox Press
