As I'm becoming more familiar with this powerful framework I've gone back over my initial code base to put in some good practice patterns in the hope of future proofing them.
One in particular is that of separating business logic and persistence.
With that in mind I have taken all references to Hibernate out of my StockManger class so that it only contains business logic. Some Hibernate DAO classes are plugged in via <property> tags in my spring config and it all looks dandy.
I can now provide a jdbc version of my DAO interfaces and hibernate could be removed altogether (if I wanted). Well not quite it seems.
Take this business method of my StockManager...
public void addStock(String userId,String locationCode, String productCode,
String container, String batch, Date bestBeforeEnd, int qty)
throws StockException {
Location l = locationDAO.findByLocationCode(locationCode);
Product p = productDAO.findByProductCode(productCode);
Stock s = new Stock(p, l, container, batch, bestBeforeEnd, qty);
l.addStock(s);
The method retrieves two 'entities' Location and Product then creates a new Stock instance and adds it to the Location retrieved. It then creates an audit and stores it.
Whats wrong then. Well, whilst I make a call to the StockDAO to store the new audit I do'nt have such a call for the new Stock or for an Update on Location which now has an extra Stock in its Set.
I'm basically relying on the HibernateSession flushing updated objects to keep the Location instance up to date.
If I don't load the Location via Hibernate but use a JDBC DAO instead the update won't happen will it ?
I could put direct calls to the DAO and create empty stubs in my HibernateDAO version but it sounds like a cludge to me so before I do I thought I'd ask for help.
It seems I'm still reliant on Hibernate even though I might not be not using it. Any idea for a way arround this, otherwise I can't see the point of seperate DAO's (unless you are only using jdbc and want an OracleDAO and a MySQLDAO etc).
I should add I don't intend on dropping Hibernate as Im a big fan but I'm trying to bed in the good practises before I move on to larger projects with Spring.
thanks in advance,
G.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-07-29
Hi Gareth,
Having a one DAO that can be used to plug in JDBC type Impls AND O/R mapping type impls is pretty difficult.
Also your DAOs might even be different between Hibernate and Toplink (due to disassociation)
There is a mismatch.. as you are finding out.
Rod's new book covers these topics in Chapter 10 - Persistence of J2EE w/o EJB.
Essentially, you should be determing the level of granularity for your DAOs based on the target persistence model.
DAOs were popularized for JDBC abstraction and vendor dependencies.. and now it is being leveraged to swap persistence strategies.
However it is not that simple.. there will need to be some changes between DAO interfaces.
You wouldnt probably want no-op methods if you can avoid it.
Hibernate DAOs should probably contain less code due to the fact that you can achieve persistence by reachability and it does dirty snapshot checking.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I'm becoming more familiar with this powerful framework I've gone back over my initial code base to put in some good practice patterns in the hope of future proofing them.
One in particular is that of separating business logic and persistence.
With that in mind I have taken all references to Hibernate out of my StockManger class so that it only contains business logic. Some Hibernate DAO classes are plugged in via <property> tags in my spring config and it all looks dandy.
I can now provide a jdbc version of my DAO interfaces and hibernate could be removed altogether (if I wanted). Well not quite it seems.
Take this business method of my StockManager...
public void addStock(String userId,String locationCode, String productCode,
String container, String batch, Date bestBeforeEnd, int qty)
throws StockException {
Location l = locationDAO.findByLocationCode(locationCode);
Product p = productDAO.findByProductCode(productCode);
Stock s = new Stock(p, l, container, batch, bestBeforeEnd, qty);
l.addStock(s);
StockAudit audit = new StockAudit();
audit.setEventTime(new Date());
audit.setUserId(userId);
audit.setProductCode(productCode);
audit.setLocationCode(locationCode);
audit.setContainerId(s.getContainerId());
audit.setBatch(s.getBatch());
audit.setBestBeforeEnd(s.getBestBeforeEnd());
audit.setQuantity(s.getQuantity());
stockDAO.store(audit);
}
The method retrieves two 'entities' Location and Product then creates a new Stock instance and adds it to the Location retrieved. It then creates an audit and stores it.
Whats wrong then. Well, whilst I make a call to the StockDAO to store the new audit I do'nt have such a call for the new Stock or for an Update on Location which now has an extra Stock in its Set.
I'm basically relying on the HibernateSession flushing updated objects to keep the Location instance up to date.
If I don't load the Location via Hibernate but use a JDBC DAO instead the update won't happen will it ?
I could put direct calls to the DAO and create empty stubs in my HibernateDAO version but it sounds like a cludge to me so before I do I thought I'd ask for help.
It seems I'm still reliant on Hibernate even though I might not be not using it. Any idea for a way arround this, otherwise I can't see the point of seperate DAO's (unless you are only using jdbc and want an OracleDAO and a MySQLDAO etc).
I should add I don't intend on dropping Hibernate as Im a big fan but I'm trying to bed in the good practises before I move on to larger projects with Spring.
thanks in advance,
G.
Hi Gareth,
Having a one DAO that can be used to plug in JDBC type Impls AND O/R mapping type impls is pretty difficult.
Also your DAOs might even be different between Hibernate and Toplink (due to disassociation)
There is a mismatch.. as you are finding out.
Rod's new book covers these topics in Chapter 10 - Persistence of J2EE w/o EJB.
Essentially, you should be determing the level of granularity for your DAOs based on the target persistence model.
DAOs were popularized for JDBC abstraction and vendor dependencies.. and now it is being leveraged to swap persistence strategies.
However it is not that simple.. there will need to be some changes between DAO interfaces.
You wouldnt probably want no-op methods if you can avoid it.
Hibernate DAOs should probably contain less code due to the fact that you can achieve persistence by reachability and it does dirty snapshot checking.