I'd like to approach the persistence problem again.  This time, I'd like 
to approach from a different angle.  Instead of explaining how things 
work and asking for advice, I'm going to make a proposal, get feedback, 
and start working on a proof-of-concept.

The idea behind this proposal is to make the smallest possible changes 
to accomplish two goals: 1) solve our Castor problems now and 2) allow 
us to someday do without Castor.   There are two steps in the proposal. 
 They can be done separately, but step #1 should come first.

Here are the steps:

**** 1) Stop using XDoclet to generate the Roller data objects.   ****

Instead of using generated data objects we will use business objects 
that are just Plain Old Java Objects (POJOs) and we will mark the POJO 
classes up with XDoclet tags so that we continue to can generate Castor 
mappings and Struts form beans using XDoclet.  Here are the reasons to 
do this:

a) Using XDoclet's EJB tags and marked up EJB EntityBean classes as the 
basis for our code generation is confusing and requires us to know how 
to use the XDoclet EJB tags even though we are not using EJB.

b) Since we are using XDoclet generated Value Objects, we cannot add new 
business logic to our beans.  The beans are just dumb data buckets, but 
we really need them to be full-fledged objects.

c) The generated data object approach makes it very difficult to use 
Castor to its fullest and especially Castor many-to-many and one-to-many 
mappings.

**** 2) Make Roller persistance mechanism pluggable ****

Currently, the Roller business tier interfaces are defined in the Model 
package (org.roller.model) and implemented in the Castor package 
(org.roller.business.castor).  This, combined with the dumb data object 
approach, means that essentially all backend business logic is tied to 
Castor.  For the sake of better modularity and with replacing Castor in 
mind, I propose that we re-organize the business tier to make the Roller 
peristence mechanism pluggable.

The business tier will be organized accross three packages Model, 
Business, and Castor.

a) The Model package contains the Roller Business Tier API which 
consists of interfaces and classes.  The model package has no 
dependencies on presentation technologies (Servlets, Velocity, JSP), and 
no dependencies on persistence technologies (Castor, JDBC).  For example:

   org.roller.model.Roller - This interface defines the entry point to 
the business tier
   org.roller.model.WeblogEntryData - This class is the WeblogEntry 
business object
   org.roller.model.WeblogManager - This interfaces defines the 
WeblogManager

By leaving the data/business objects in org.roller.model and be leaving 
their names unchanged, hopefully we will be able to do these changes 
without making any changes in the Presentation portions of Roller.

b) The Business package provides support for and implements the 
interfaces in the Roller Model, but still has no dependency on 
persistence technologies (Castor, JDBC).  This package also defines the 
Data Access Object interfaces to be implemented be persistence 
providers.  For example:

   org.roller.business.RollerImpl - implements Roller
   org.roller.business.WeblogDAO - Defines the Weblog Data Access Object 
interface
   org.roller.business.WeblogManagerImpl - implements the WeblogManager 
interface

The Business WeblogManagerImpl class will contain the business logic 
that was formerly in the Castor WeblogManagerImpl class.  The new 
WeblogManagerImpl class will rely on WeblogDAO, an interface, for all of 
its persistence needs.

c) The Castor package provides an implementation of the Roller DAO 
interfaces using Castor JDO and XML.  For example:

   org.roller.business.castor.WeblogManagerDAOImpl - knows how to store, 
retrieve, and do other related things with weblog objects such as 
WeblogEntryData, WeblogCategoryData, and CommentData.

I plan on implementing the new RefererData and RefererManager using this 
new proposed architecture as a proof of concept.  I'd like to move to 
XDoclet 1.2-beta, implement step #1 above, and then release Roller 
0.9.7.  After 0.9.7, I'd like to move to step #2.

Let me know what you think of these ideas.  I'd like to fix things 
before we move too far along.

- Dave

-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html