RE: [Hibernate] Using hibernate - best practices

[Urberg, J. <ju...@ve...>]

Ralf,

This is what I have done:

1) Created a Database interface that has common database stuff like connect,
commit, rollback, lookup, update, delete, etc.
2) Created "Repository" interfaces that have any database functionality for
a specific domain object or group of domain objects (I got this idea from
http://www.domainlanguage.com/).  If you want to be really safe, you should
put the update and delete in the repository too.
3) Created implementations of database and repository interfaces using
Hibernate.

Example: Lets say I have an Invoice object that contains InvoiceLine
objects.  I have a requirement to load overdue invoices and do something to
them.  I would end up with code like this:

     InvoiceRepository repository =
database.getRepository(InvoiceRepository.class);
     List overdueInvoices = repository.getOverdueInvoices();  // gets
invoices and associated objects
     database.beginTrans();
     for (Iterator i = overdueInvoices.iterator(); i.hasNext(); ) {
          Invoice invoice = (Invoice) i.next();
          invoice.doSomething();
          repository.update(invoice);
     }
     database.commit();

The InvoiceRepository would be implemented like this:
    
     public class HibernateInvoiceRepository {
        public void setDatabase(Database database) { _database =
(HibernateDatabase) database; }
        public List getOverdueInvoices() {
             return database.getSession().find("<hibernate query>");
        }
        public void update(Object object) {
              database.getSession().saveOrUpdate(object);
        }
    }

Then later, if you need to change your application to work against a
database not supported by Hibernate, you could implement repositories
against it.

Hope this helps,
John
 

>  -----Original Message-----
> From: 	Ralf E. Stranzenbach [mailto:mo...@re...] 
> Sent:	Thursday, November 14, 2002 12:53 PM
> To:	hib...@li...
> Cc:	mh...@be...; Ralf Stranzenbach Edmund
> Subject:	[Hibernate] Using hibernate - best practices
> 
> Hi,
> 
> at the moment i spent some time on a small application using hibernate.
> I've did most of the domain's modeling and implementation. Now i have to
> decide where to place the database (say hibernate) dependent code.
> 
> *	Put everything into the domain classes.
> *	Implement something like a "Home" interface
> *	Implement some sort of component-like / "Service" interface
> 
> Domain Classes with database access
> This implementation strategy seems to be the simplest one of all. Database
> access is at most implemented as static methods of the domain class. But
> unfortunately this establishes a very strong link between the domain
> classes and the persistence provider. If i decide to change the
> persistence provider for any reason, i have to modify all domain classes.
> 
> Implementation of a Home-Interface
> This solution seems to keep things moderate simple. Each domain class
> (e.g. Actor) owns one associated "home interface" (e.g. ActorHome). Using
> some Factory it is possible to obtain a specific implementation (e.g.
> ActorHomeHibernateImpl) of that interface. All communication with the
> underlying persistence provider is channeled through this interface. The
> domain classes will be (almost) free of code dealing with the database
> (Lifecycle etc. seems to be still a problem). In this case i have to
> provide some abstraction for the persistence services (update(), delete(),
> TX-management).
> 
> Implementation of Service like structures
> This is more or less the same idea like above but with coarser
> granularity. In this case i think about interfaces covering note single
> domain classes but semantic groups of them. In this way something that
> smells like a "component" (with its own lifecycle) could be implemented.
> Using this strategy the Service-Interface would behave also as a service
> provider for the domain classes. But this design could offer some chances
> to reimplement parts of the application using different persistence
> providers (requires the domain classes using the Service-Interface if
> crossing "component" borders).
> 
> At this moment i'm not sure wich basic design i should use. Please drop me
> some notes about this topic.
> *	Which is your preffered strategy?
> *	Why have you choosen your way?
> *	What are the benefits or the drawbacks?
> 
> regards,
> Ralf E. Stranzenbach