Tapestry spring hibernate integration [Abstract]

Tapestry spring hibernate integration [Abstract]

Eugenecao published on-10-10

Franksoo is my project manager. Some time ago, the company decided to create a new J2EE secondary development platform to replace the company's original development platform. The company asked franksoo and I to form a platform development project team and franksoo as the project manager. Now the integrated development stage of this platform is over and enters the project application stage. The following is a summary of our integration work. We will introduce the problems we encounter at work and the solutions we have chosen. 1. Architecture Selection First, we all agree to develop a complete platform based on our existing capabilities without enough time and resources. Only by selecting a number of excellent projects for integration among many existing open-source projects can the project be completed on time to achieve the project goal. However, before the platform project starts, we had our own ideas on the platform's technical architecture. Franksoo's original idea was STRUTS + spring + hibernate, while my idea was tapestry + hibernate. However, franksoo is very open. After I showed him the typical sample workbench of tapestry and introduced the component-based programming method of tapestry, he agreed to use Tapestry as the framework for implementing the WEB presentation layer. I think franksoo's previous struts development experience (painful) is also one of the factors for his 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, we have all voted for this most successful open-source ORM project. ^_^ Finally, we confirm that the technical architecture of the platform is tapestry + spring + hibernate. 2. Architecture Integration The initial platform architecture draws on an article to introduce how to integrate tapestry and springArticleThe architecture mentioned in [1: The tapestry at the web layer is responsible for data input and output, response to user events, and input validation. It accesses the pre-loaded webapplicationcontext (provided by spring and contains all service beans) obtain the service beans at the service layer and delegate all business operations to them. The bean at the service layer is responsible for the use case logic, and the domain-related logic is delegated to the bean in the domain model for implementation. the Service uses Dao to persist the domain model. the Service manages database transactions and hibernate sessions (through spring declarative Transaction Management and hibernate session management integrated with it ). another important task of the service layer is permission and access control. Domain model is responsible for displaying the data in the problem domain and domain logic. Dao uses hibernate for persistent data and query. In implementing Dao, we use hibernate Dao support of spring, which greatly simplifiesCodeIn many ways, only one simple line is used. Interestingly, the amount of Code completed by the last hibernatedao is more than half of the mockdao code I wrote. This architecture has obvious advantages, clear layers, and clear responsibilities at each layer, which facilitates hierarchical design and development. Combining the IOC of mock and spring, unit test is also very easy. in addition, the backend (Service, domain model and Dao) Code does not depend on the Web container or the API of the EJB container, and the portability is very good, the same Code can be used in Web apps or in common Java apps. You only need to change the UI Layer. According to this integrated architecture, we implement a simple instance, implement list paging query and display, add, delete, and modify data, and provide a general query Mechanism Based on Hibernate criteria query. With middlegen and velocity, We can automatically generate hibernate ing files, Entity classes, and Dao from the created database table structure, greatly reducing the workload. We also conducted a stress test on this small example (the data volume during the test is 0.1 million records) to determine that the platform does not have performance problems. Through this example, we have gone through the entire architecture and summarized the development processes and work to be done when using this architecture for development. 3. problems that plague us In the implementation example and the current project application process, we found a number of headaches, some solved, and some did not. Question 1: Do you want to use DTO? In the above architecture, we did not specify how data transmission between the service and the web layer is performed. We have discussed whether to use DTO for a long time, and the final conclusion is no. There are two main reasons for using DTO: 1. Reduce the number of method calls between the web layer and the service layer, and pass the data required by the Web to the Web through a method call. 2. Isolate the domain model and web layer. The first reason is that it is not true under our architecture. Because our architecture is centralized, web and service are in the same JVM, method calls between them are not greatly consumed by EJB remote access. The second reason still needs to be considered. If the domain model object can be transferred to the web layer, modifying the domain model will affect the web layer. If DTO is used, the changes in the domain model implementation will not affect the web. However, a large number of changes are not changes in the implementation of domain models, but changes in the domain model interface. For example, an attribute is added to a domain model object, which must be modified by the user, at this time, you must modify the web layer, whether or not DTO is used. With DTO, you need to maintain a large number of objects or their generators. This is a very boring and error-prone job. Based on these considerations, instead of using DTO, we chose to directly upload the domain model to the web layer. The following figure shows the modified architecture diagram (Haha, I modified another person's figure [2]). Question 2: entity like domain model or rich domain model? We use middlegen to automatically generate the hibernate ing file, entity class and DAO class, but the generated entity only contains simple attributes and the getter and setter methods. So we encountered a problem: do our domain model need to contain domain logic? If so, how can they be combined with the automatic generation tool? After the discussion, we think that a rich domain model is very necessary to reduce repeated code in the service and improve reusability. How to combine with automatic generation? Use the <meta> label to generate abstract base classes. We inherit these automatically generated base classes and add business methods. Question 3: Model Driven or data driven? We have had a heated discussion using model driven or data driven. We were mainly influenced by Rod Johnson [3] and adopted the data driven method. First, design the database, generate the database table, and then use middlegen to reverse generate the hibernate ing file and entity and Dao. However, after entering the project application, we found that this method has two problems: A) database design only describes the static data to be managed by the system. We still need to perform 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 to optimize performance, several data that should be separate entities may be put into one entity. In this way, it is unacceptable to directly map such coarse-grained entities into Entity classes. The classes produced by the object-oriented analysis and design model are quite fine-grained. In this case, we have to perform object-oriented analysis to determine whether the large table with a coarse granularity should be mapped to those fine-grained objects. Maybe we should try Model Driven and use andromda to generate domain model, Hibernate Dao, Hibernate mapping, database table, simple service and front-end tapestry page. Question 4: how to manage the hibernate session lifecycle? We use the session-per-transaction mode for the life cycle of the hibernate session, but do not use the open session in view mode. Although the hibernate team believes that this method is not good, and both freeroller and Atlassian confluence use the open session in view mode, we are not sure about the possible impact of this method, so temporarily discard it. If the web layer needs to access the data of lazy load, it must first call the service method to obtain the data. Question 5: How can I differentiate Use Case Logic and domain logic? Service is responsible for Use Case Logic, and domain model is responsible for domain logic. This Division looks good, and it is very troublesome to implement it. How to determine what is Use Case Logic and domain logic? TBD. Question 6: How to Determine the service granularity? This problem is really annoying. We used to consider using usecase controller. Each usecase corresponds to a service, but we found that the reusability is too low, and the same function must be reused in many places. Another method is to use package level service, and each package serves as a service, which can be reused, but it is too dead to be good. There is no good way now, so we have to determine the number of services required according to the specific situation during detailed design. TBD. Question 7: How to Set permissions? How to check? Permission setting is also a headache. We wanted to set permissions according to use case. Each use case has one permission. When a role is set, permissions with clear business meanings are processed directly. However, a problem is found during permission verification: if the permission is verified in the service method, and this method is used in multiple use cases (reuse service ), the service method needs to check Multiple permissions. If each service method corresponds to one permission, the permissions are too detailed, unlike the use case permission, which represents a complete business. it's really troublesome! TBD. Quake Wang: Question 1: Do you want to use DTO? No DTO directly transmits the domain object to the web layer of tapestry. Using tapestry, it provides powerful data binding and component functions, which are very convenient. Question 2: entity like domain model or rich domain model? Domain model does not include complex domain logic. It serves as a data model bean and adds some simple logic. For example, when addchild is used, it sets a simple logic such as child's parent. Question 3: Model Driven or data driven? This is not a big problem for me. I am used to it. In my opinion, whether it is model driven or data driven, the final design of the two should be similar for the same requirements. I have considered both the two sides. I have to consider the structure of the database while making the model, and then make corresponding adjustments. There is no problem in using it. No code is generated, but hibernate eclipse plugin (hibernate synchronizer) is used to help me do some code assist. Question 4: how to manage the hibernate session lifecycle? Currently, open session in view is not used. Just like you, all required objects are prepared in the service. Question 5: How can I differentiate Use Case Logic and domain logic? The domain model does not contain domain logic. Question 6: How to Determine the service granularity? Because domain model does not contain domain logic, the service functions are segmented and reused as much as possible. A package may have multiple services, so it feels okay. Question 7: How to Set permissions? How to check? This is also a problem I did not think about, because different requirements and permission settings are different, it is difficult to use AOP for a general aspect. 1. DaO approach: Currently, I do not create a Dao for every domain object, but a Dao (persistencemanager) for the entire system. There are only three methods: Create, update, and delete entity. In addition, write a Dao for querying (querymanager), use the named query of hibernate for common queries, and use criteria for dynamic queries based on user input. I don't know how you do it? In addition, criteria and named query are both hardcode. When the object attribute name is changed, remember to manually modify the code, unit test is hard to cover all the code in criteria search and named query, which is not very convenient at present. 2. Integration of spring and tapestry Currently, only spring is used to connect to the service layer. tapestry is called through the Global (playing the role of service locator) object. There are still many dirty codes on the domain tapestry layer, in fact, we can also use AOP to solve this problem. If we can get all the actions from spring like webwork2, we can get the page through spring. Listeners is much more convenient, but tapestry also has its own class enhancement function. It seems that there are some conflicts and there is no good idea at present. By the way, we recommend three tools (all of which are eclipse plugin) in my project ): 1.Http://spindle.sourceforge.netEssential for developing tapestry 2.Http://springui.sourceforge.netAuxiliary tool for writing spring application context File 3.Http://www.binamics.com/hibernatesynch/Auxiliary Tools for hibernate development. Http://javamen.blogdriver.com/javamen/299858.html