Previous: The most beautiful MVC, ORM program is elsewhere - Ruby On Rails
Rails's appearance, benign impacts the Spring Hibernate architecture you currently use. There is an impact is good, otherwise EJB2 and Struts are now still a river. This paper mainly describes the advantages and disadvantages of Hibernate 3.0 (H3) and Rails Active Record (AR) in definition and use of Domain Objectt, more importantly, how to reconstruct the framework.
Pojo definition 1.ar definition Pojo only like this
Class Company 2. Compare the Hibernate 2.0 era programmer must maintain both POJO and HBM's two files. There is no size, and if you use xdoclet, it is more redundant. At this point, the definition of Active Record is simply a productivity of the productivity, and there are several times different from the number of code lines. 3. Fortunately, Hibernate3.0 has supported Annotation declarations. Finally, the HBM file can be discarded, and the H3 will also have a table name and the intelligence of the name of Auto Mapping, just like this: @Entitypublic class Company implements Serializable {@Id public Long getCompanyNo () {return companyNo;} public String getName () {return name;} @ManyToOne @JoinColumn (name = "boss_id") public Boss getBoss () {return regionalCenter;} @Transient String getLengthinmeter ()} The company name is defined by automate mapping, @MANTOONE defines the relationship, @ Transient defines that this property does not need to be persistent. 4. Finally, I feel that it is better than hibernate3.0. After all, Ar putting things all the names all the names allo-map. I have to open the database of Schema. Moreover, H3 can define complex relationships and conditions than Ar. However, H3 Annotation only goes to Beta1, but also hurry. Domain Model uses the first two belong to the Domain Model scope of Martin Fowler, but AR is of course Active Record mode, and Hibernate is Data Mapper. Active Record Because Totally has only one Pojo object, almost compulsively uses DDD mode. Data Mapper mode According to Martin, in order to completely decouple the database structure and domain object, an EntityManager class (JDO is called persistencemanager, hibernate is called session. Toplink is called UnitOfwork), which triggered DDD (Domain Driven Develope) and anemia Pojo, a service script, a service layer, etc. Features of Active Record: Represents a line of data in the database, with domain objects, domain methods, and persistence methods, and the Finder method is defined as a static method of classes. At the same time, because CAT is inherited in ActiveRecord, there is a method such as New, Save, Find, Find_all, etc. by default. Cat = cat.find (pkid) Cat.catch (mouse) cat.save For extreme OO molecules and small white programmingists, the above code is really great. In Hibernate, because there are sessions, there is a Manager class, there is a service layer, and even a DAO layer exists, the combination is blurred. The cause of the debate is simple, because the domain method will only operate your own properties in extreme ideals, such as counttax (), and many cases require dynamic execution of the Find () method from the database to raise some objects to participate in the transaction There are many time to pull or others. Therefore, how to combine the service, manager, and DAO changes are the beginning of DDD debate. The saliva of DDD is already too much, and it is actually the level of advanced DAO. Here is just a way: 1. Some extremely clean practices: Each Manager is only responsible for working with your own Pojo, handing the integrated business to the Service layer, which is complex SERVICE mode that makes Martin. In fact, this is the mode of re-degrading the Manager class into a table entrance. Since we advocate OO, we should be courageous, and have never seen things that don't know others. I am afraid that the most dependent on the object is abstracted into an interface. Relying on a very common interface than relying on a particular implementation. 2. Another most popular clean approach: Pojo has its own domain attribute, and the domain method, without DAO handle. This mode is like this even more exemplary examples. In fact, as mentioned earlier, this obviously thinking that the domain method is the number of properties and related objects of the Temple of the field, and the POJO holds DAO pointer is required. So Pojo should take advantage of Spring, using IOC, very elegant while holding Dao and his session, and hope that there is a famous example to provide such a demonstration. 3. In the Public class orderManager {private orderdao orderdao; public void placerder (ORDER) {ORDERDAO.STOREORDER (ORDER); ORDERDAO.UPDATEINVENTORY (ORDER);}} (Excerpted from 1. Business methods and persistence methods are not strictly distinguished, they are mixed in ORDERDAO, and they can have persistent methods in business operations. 2. ORDERDAO has the operation of performing objects (inventory objects) other than Order. 3. The business object is a Manager object, not the Pojo object --ORDER object, the so-called POJO should still be anemia, the drama is not big. (Let Pojo hold Dao handles are not easy in Spring) It can be seen that the ROD is very very very practical. Rod said that when some of the persistent plans come, or when you want to make the code clearly, you need to separate Data Acject Object and Business Object. improvement plan 1. First, try to use Hibernate3.0 Annotation Beta1, remove the HBM file, and simplify configuration using her automapping function 2. Use reflection, strengthen the parent class of the Manager class, and have a batch of methods. Although MDA can automatically generate these methods in subclasses, I think it still has the cost of maintenance and code, so even if the Code Generation should be used to use the reuse technology to minimize the code to generate the code generation, not because With the code generation, you don't pay attention to the abstract reuse of the code. 3. Study how to make POJO elegant holding a DAO handle under the Spring system to realize real DDD programming. Of course, you can also do this, continue the actual mode of ROD. 4. Refer to Rails to study how to increase validates_uniqueasons_of: subdomain in the parent class. 5. Refer to Rails to study Hibernate3's administrative management and OBServer mode applications. Finally, there is a Hibernate VS Rails on TSS, written by the owner of
