TapeStry Spring Hibernate integration work summary [transfer]
Below is the text I sent in the Spring Chinese Forum, but I didn't get a response, I hope to get help here. Thank you ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -------------- TapeStry Spring Hibernate Integration Work Summary Cyberwing Frankso 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, introduce the issues we have encountered in our work, as well as our solutions. 1. First, we agree to our existing capacity, there is not enough time and resources. Develop a complete platform. 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, the most successful Open source ORM project, we all voted ^ _ ^ Finally we determine the platform's technical architecture is TapeStry Spring Hibernate. 2, the architecture integration initial platform architecture draws on how to integrate TapeStry and Spring articles [1 The architecture mentioned in: The Web layer TapeStry is responsible for data input output, responding to user events, and entering the work of the verification, by accessing the preloaded WebApplicationContext (provided by Spring, including all service beans) to get the service bean for the service layer The business operations are delegated to them. The Bean of the Service layer is responsible for the use case logic, Domain-related logic entrustments to the bean in Domain Model. Service is completed on Domain Model through DAO. Service is responsible for database transactions and Hibernate Session Management (through Spring Declarative Transaction Management and Integrated Hibernate Session Management). Another important job of the Service layer is permission and access control.
Domain Model is responsible for representing the data of the problem and Domain logic. DAO uses Hibernate persistent data as well. When implementing DAO, we use Spring Hibernate Dao Support, which greatly simplifies the code, and many methods are complete with simple lines. Interestingly, the final completed Hibernatedao code is actually more than half of the MockDao I have written more than half of the architectural advantages, clear level, and the responsibilities of each layer are also clear, facilitating hierarchical design and development, combination Mock and Spring IOC, Unit Test is also very easy. And the code of the service, Domain Model and DAO does not rely on the web container or the API of the EJB container, the portability is very good, the same code can be in the web app Use can also be used in a normal Java app, just replace the UI layer. Follow this integrated architecture, we implemented a simple instance, implement the list paging query and display, data adding and degeneration, based on Hibernate Criteria Query provides a comparison A general query mechanism. Using MiddleGen and Velocity we can automatically generate Hibernate mapping files, entity classes, and DAOs from the already built database table structure, which greatly reduces 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. Phambering our problem in implementation examples and current project applications, we discover 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? We use MiddleGen to automatically generate Hibernate mapping files, Entity classes, and DAO classes, but generated Entity only contains simple properties and getter, setter methods.
So we have encountered a question: Does our Domain Model do not include Domain Logic? If included, 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 unacceptable if this extreme coarse particle size entity is mapped directly into an 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 Freeroller and Atlassian's Conflunce use Open session in view model, but we have no well-grasp of the impact of it, so it is temporarily discarded. If the web layer wants to access the data of Lazy Load, you need to call the service's business method to get the data. Question 5: How does Uses logic and Domain Logic distinguish? 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 determine what is use case logic, what is DOMAIN logic? 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 it must be too low, and many places must be multiplexed the same function. Another way is to use Package Level Service, each Package is a service so that it can be 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. 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 have been found during the authority verification: If the permissions are verified in the service method, and this method is used in multiple usage (multiplex service), then this service method needs to check multiple permissions; if each The service method corresponds to a permission, then the permissions are too thin, not like a complete business as the USE case authority. 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. http://www.springframework.org/docs/DOCS/ Reference / View.html # View-Tapestry [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/wiringWebapps.html [3] Expert One-ON-One J2EE Design and Development, Rod Johnson, 2003, Wrox Press.20: 58 | Comments (0)
Vo, Po, Bo, DTO ... Identify some nouns Vo, Po, Bo, DTO ... identify some nouns:
1, VO: It is actually vague, usually refers to ValueObject and ViewObject
2, View Object: Interface shows the object, such as struts FORMBEAN
3, Value Object: The early referred to as ValueObject and Transfer object. In fact, the true meaning of Value Object is its content, not identity.
4, Data Transfer Object (DTO): Data transfer objects, in different levels of applications, in a distributed application,
