J. Matthew Pryor wrote:
> Care to share any further insights about your approach?
I have a few more notes that might be useful to you.
Each entity is an XDoclet-enabled abstract bean that extends a generic
base class EntitySupport. In the implementation of ejbLoad() in
EntitySupport I have this:
public void ejbLoad() throws EJBException, RemoteException
{
dao.load();
}
i.e. the load behaviour is delegated to a DAO object. The DAO is
reponsible for the mapping between the instance and persistent storage.
The DAO object is inited in setEntityContext(), also in EntitySupport
since it is generic:
public void setEntityContext(EntityContext aContext) throws
EJBException, RemoteException
{
ctx = aContext;
dao = DAOFactoryBuilder.getFactory().getDAO(this);
}
By having a factory for the factory I can have multiple strategies for
persistence and simply choose by setting the right factory to be
returned from getFactory(). Currently I have JDBC, XML, and CMP (i.e.
the DAO does nothing). JDBC is for production, XML is for development
and testing, and CMP is for the cases where a CMP engine can take care
of things. I can easily extend this list by making new DAO's and a new
factory for them, and this without having to change my code at all.
As you can see the DAO object is associated with the instance in the
getDAO() call, so there's no need to pass it in during load() invocations.
The DAO is also responsible for the finders, so right now I have 4 DAO
classes per entity: a base class with abstract finder methods, and one
for each persistence method with concrete invocations of the finder
methods. In my entitybeans finder methods I can then do like this:
/**
*
*/
public ForumPK ejbFindByPrimaryKey(ForumPK id)
throws FinderException
{
return (ForumPK)((ForumDAO)dao).findByPrimaryKey(id);
}
i.e. I cast the DAO to the entity-specific base class, and invoke the
finder on it. This invokes either JDBCForumDAO.findByPrimaryKey() or
XMLForumDAO.findByprimaryKey() (the CMP case won't call the beans
ejbFindByPrimaryKey method in the first place).
By doing this I can begin coding a new entity with an XML DAO
implementation, which is useful because everything ends up in readable
and editable XML files. When it is tested, I code the JDBC DAO, and test
it for stability only (feature tests have been done with XML already),
and use that for production.
In this way I get the rapid development style of using XML, and the
scalability and transactional features of using JDBC.
Makes sense?
/Rickard
--
Rickard Öberg
Chief Architect, TheServerSide.com
The Middleware Company
_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
