Accidentally saw an article written by L_walker in 2003-9-15 about the encapsulation of hibernate in DAO was put to the essence. And think of a package method I used last year in my own project development, which I thought was entirely another way of thinking. So take it out and discuss it, and maybe luck will be the essence.
Take a look at the encapsulated calling code:
Java code:
/**
* For Management ... The Oracle DAO
* <p>company: </p>
* @author Chenxu
* @version 1.0
*/
public class Useroracledao {
/**
* Add a user
* @param vo Uservo
*/
public void AddUser (Uservo vo, Boolean Needtrans) throws
appexception {
Dohibernateproc_save Dproc = new Dohibernateproc_save (new object[] {
VO}, Needtrans);
Dproc.doproc ();
}
/**
* Update a user
* @param vo Uservo
*/
public void UpdateUser (Uservo vo, Boolean Needtrans) throws
appexception {
Dohibernateproc_update Dproc = new Dohibernateproc_update (new
Object[] {
VO}, Needtrans);
Dproc.doproc ();
}
/**
* Delete a user
* @param vo Uservo
*/
public void Deluser (Uservo vo, Boolean Needtrans) throws
appexception {
Dohibernateproc_delete Doproc = new Dohibernateproc_delete (new
Object[] {
VO}, Needtrans);
Doproc.doproc ();
}
/**
* Get all user
* @return List
*/
Public List Getalluser (Boolean Needtrans) throws Appexception {
Dohibernateproc_getlists Dproc =
New Dohibernateproc_getlists (
"From Uservo as T where (t.deleted is null or t.deleted!=true)", Needtrans);
Dproc.doproc ();
Return (List) Dproc.getresult ();
}
/**
* Query user by ID
* @param name Long
* @return Uservo
*/
Public Uservo Getuserbyid (Long ID, Boolean Needtrans) throws
appexception {
Dohibernateproc_getobject Dproc = new Dohibernateproc_getobject (new
Object[] {uservo.class, id}, Needtrans);
Dproc.doproc ();
Uservo EType = (Uservo) dproc.getresult ();
return eType;
}
In the above DAO implementation class, the call code for hibernate does not contain any direct calls to hibernate APIs, and there is no need to handle hibernate-related exceptions, just for my 5 wrapper classes. respectively:
Dohibernateproc_save------Package Hibernate save Operation classes
Dohibernateproc_update class for update operations------package Hibernate
Dohibernateproc_delete------Package Hibernate's Delete operation class
Dohibernateproc_getlists------Package Hibernate HQL Query Operation class
Dohibernateproc_getobject------Package Hibernate's class of how to query by ID
;
At the same time, the method of invocation is also concise, which includes most hibernate operations.
This enables the separation of DAO developers and specific hibernate operations, which can be
Hibernate is a very familiar person to develop code that maintains this part of hibernate operations, and the business module does not need to have any knowledge of this. Avoids the confusion caused by different module developers modifying hibernate code in their own DAO.
Comparison of two package ideas:
L_walker's idea is to encapsulate the common approach (Hibernate API), and my idea is to encapsulate common crud operations, which are business logic-oriented encapsulation.
The result of L_walker encapsulation is the invocation of the basic operation of Hiernate in its DAO, such as: Open transaction, open session, close session, close transaction, You also need to capture Hierbnate's exception hibernateexception.
And the result of my package is that
1, only need to call my encapsulation class in a uniform way;
2,dao developers do not need to know anything about hibernate;
3, calling my wrapper class typically requires just 2·3 lines of code, without capturing proprietary exceptions
(This exception has been effectively handled correctly in the encapsulation Class). The code volume is streamlined. Odd Little.
4, because the change caused by Hibernate operation error or improper probability greatly reduced, because is unified code, will be unified modification;
Finally, please robbin the long-admired. It's a pleasure.
