Dominic
DaSilva and
Mike
Cannon Brookes both read my recent
Roller
persistence proposal as a proposal to escape from the
Castor persistence framework. That
is really not really the case. I want to make it easier for Roller to
make full use of Castor and at the same time I want to separate the
Roller business logic from from the Castor-based persistence logic.
I don't like the fact that the Roller business tier is littered
with calls to Castor and I want to separate concerns.
Why can't Roller make full use of Castor now? The answer is in
the history. Roller is constrained by it's own EJB legacy.
When I originally wrote Roller back in the Spring of 2001, I
implemented the Roller manager objects as EJB Session Beans and the
domain objects as EJB Entity Beans. I quickly learned that EJB
Entity Beans are way too heavy. I started to take advantage of
XDoclet's ability to generate light-weight Value Objects.
Eventually, I came up with an architecture where the presentation
tier knew nothing about EJB. The presentation tier only knows
about the business tier interfaces and the Value Objects that those
interfaces returned or accepted as arguments. Once I got to that
point, I was able to completely swap out EJB and switch over to Castor.
So, Roller uses Castor for all persistence now, but it still uses the
EJB Value Objects generated by XDoclet. To add a new persistent
object to Roller, you create an abstract class that extends
javax.ejb.EntityBean and you mark that class up with XDoclet @ejb,
@castor, and @struts tags. This new class will not actually be
used by Roller at runtime. It is used at build time as the basis
for XDoclet code generation that generates Roller's Value Objects, Castor mapping file, and Struts form beans.
As I state in the proposal, I'd like to stop using the Value Objects
for persistence. They are just dumb data buckets and we need them
to be real business objects. That said, I hate the idea of
hand-maintaining code that was once generated. I'm conflicted.
Now, on to the other issue: separating the Roller business logic
from from the Castor-based persistence logic and possibly attaining persistence layer pluggability. I feel less
strongly about this because 1) if Roller moves from Value Objects to
full fledged business objects then much of the business logic can
reside in those objects and 2) Castor works pretty well and at this
point no other persistence framework offers a compelling reason to
switch.
Like
Dominic, I'm on a "quest for a good Java/XML O/R mapping
framework." None of the competing persistence frameworks offer me
a really compelling reason to do the work required to switch, so I hope
to learn to use Castor better and and at the same time try to design away some of that work.
One other thing. I tried to get some design assistance from the
Castor and XDoclet folks in the past, but I came up short.
If you are an XDoclet/Castor expert, please speak up and help us
make Roller a best practices example of XDoclet/Castor usage.
Read the Roller
article,
read the
proposal,
get on your high horse, stand on your soap box, or climb the stairs
into your ivory tower, and tell us what we are doing wrong and how we
can do better.