Hibernate3.0 vs rails active record

Previous Article: The Most Beautiful MVC, the orm solution was originally elsewhere-Ruby on Rails

The emergence of rails has a positive impact on the current spring + hibernate architecture. It is good to have an impact. Otherwise, ejb2 and struts are still integrated.
This article describes the advantages and disadvantages of hibernate3.0 (H3) and rails active record (AR) in defining and using domain objectt. More importantly, after the impact, we plan to restructure and improve our own framework.

Pojo Definition
1. ar defines pojo with just a few

class Company < ActiveRecord::Base
   has_many   :clients
   belongs_to :boss
end

Among them, attributes such as "company name" have been automate mapping, while has_many and belongs_to statements clearly declare the relationship with clients and boss.

2. Comparison of the hibernate2.0 Era
The programmer must maintain both the pojo and HBM files and repeatedly declare them one by one. Moreover, XDoclet is even longer. At this time, the definition of active record is almost the liberation of productivity, and the number of lines of code between the two companies is dozens of times different.

3. Fortunately, hibernate3.0 supports the annotation statement.
Finally, you can discard the HBM file. At the same time, H3 also has the intelligence of table name and column name auto mapping, like this:

@Entity
public 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 automate mapping, @ manytoone defines the relationship, and @ transient defines the property and does not need to be persisted.

4. Finally, I think
In comparison, it seems that the hibernate3.0 method is better. After all, ar has lost all its column names in auto-map mode. You need to open the database schema by yourself. In addition, H3 can define complex relationships and situations than AR. However, the annotation of H3 is only available in beta1, so we have to work hard.

Domain Model usage
First, both belong to the domain model category mentioned by Martin Fowler, but of course Ar isActive recordAnd hibernate belongsData mapper.

Active record because totally only has one pojo object, it is almost forced to use the DDD mode.
The data mapper mode, according to Martin, adds an entitymanager class (JDO calledPersistencemanagerHibernate is calledSession. Toplink is calledUnitofwork), Which leads to endless debates about DDD (domain driven develope), anemia pojo, and transaction-script service layer.

Features of active record: Represents a row of data in the database. It has the domain attributes, domain methods, and persistence methods of domain objects. The Finder method is defined as a static method of the class. At the same time, because Cat inherits activerecord, it has new, save, find, find_all and other methods by default.

cat = Cat.find(pkId)
cat.catch(mouse)
cat.save

ForExtreme oo molecules and little white programmersThe above code is really great.

In hibernate, the combination becomes merged because of sessions, Manager classes, service layers, and even Dao layers.

The cause of the debate is simple, because domain methods only operate on their own attributes, such as counttax (), in extreme ideal cases. In many cases, they need to dynamically execute find () the method pulls some objects from the database to participate in the transaction. In many cases, other objects are pulled. Therefore, how to combine services, managers, and Dao is the beginning of the DDD debate.

There are too many saliva about DDD, and I am still at the level of advanced Dao. Let's just say:

1. Some extremely clean practices:
　Each manager is only responsible for the actions related to his pojo and submits the integrated transactions to the service layer. This is a complicated service mode that makes Martin complain.
In fact, this is the mode to re-degrade the manager class into a table entry. Since we advocate Oo, we should be brave in association and never have seen anything unrelated to others. If you are afraid, you can abstract the dependent object into an interface at most. Dependency on a public interface is stronger than dependency on a specific implementation class.

2. Another common clean-up approach:
Pojo only has its own domain attributes and domain methods without Dao handles. This mode is applicable to many famous examples. As mentioned above, this is obviously wishful thinking that the domain method is the attributes and related objects of the domain object itself. pojo needs to hold the DaO pointer.
Therefore, pojo should use spring and IOC to elegantly hold Dao and his session when necessary. It is hoped that such an example will be provided.

3. In Rod's <withdout EJB>, it is like this:

Public class ordermanager
{
Private orderdao;
Public void placeorder (order)
{
Orderdao. storeorder (order );
Orderdao. updateinventory (order );
}
} (From the <withdout EJB> example)

What do you see?
1. There is no strict distinction between commercial methods and persistence methods. They are all mixed in orderdao and can carry persistence methods in commercial operations.
2. orderdao performs operations on objects (inventory objects) other than orders.
3. The business object is the manager object, not the pojo object-order object. The so-called pojo should still be anemia, and the drama is not big (it is not easy for pojo to hold the DaO handle in spring)

It can be seen that rod is very, very practical.
Rod said that data acess objects and business objects must be separated only when there are other persistence solutions or you want to clarify the code.

Improvement Plan

1. First, try to use hibernate3.0 annotation beta1, remove the HBM file, and use her automapping function to simplify the configuration.

2. Use reflection to enhance the parent class of the manager class and have a batch of default methods.
Although MDA can automatically generate these methods in sub-classes, I think there is still a cost of maintenance and code after generation, so even if it is code generation, you should also use the Reuse Technology to minimize the code and then generate the code. You cannot ignore the abstract reuse of the code because of code generation.

3. Study How To Make pojo elegantly hold Dao handles in the spring system to implement true DDD programming.
Of course you can leave this alone and continue with the actual rod model.

4. Refer to rails to study how to add a function such as validates_uniqueness_of: subdomain to the parent class.

5. Refer to rails to study event management and observer Mode Applications under hibernate3.

Finally, there is an article about hibernate vs rails on TSS, written by a co-author of