This week I've embarked on using OJB as a persistence framework in my second major project, and I'm very enthusiastic about it. When I first started learning OJB, Hibernate hadn't yet shot to the prominence it has now, and sometimes I wonder whether I should switch midstream... but I haven't found any real reasons not to use OJB, and I know it at least a little better than Hibernate. My co-developer reviewed the debates between the two out there and concluded that it's basically a religious issue.

Torque requires autogeneration of persistence code, which seems like an outdated strategy. I think there are some neat things in the Torque libraries, but I doubt that a new project would choose it over either Hibernate, OJB, or some JDO implementation which does all of that at run-time.

I'm still generally an EJB skeptic. I have a feeling that unless one really wants to be ready for a clustered deployment, they are overkill for most purposes.

No matter which one of these you use, you're best off defining some kind of persistence interface so that you can switch to the next "flavor-of-the-month" when your needs change. With this, the biggest obstacle is how to discover your implementation interface, but I've been pretty happy with Commons Discovery for that; I've written a "DiscoverySupport" class for internal use here that encapsulates the most common use pattern into something that is really trivial to use. I'm interested in the rapidly developing "microkernel" field (HiveMind, Keel, PicoContainer, Spring...) but haven't made the time to choose one of them.

To bring this back to being slightly on-topic, I wonder if Struts should formally adopt one of these microkernel tools (or build/adapt one) in the future? Or is that best left up to each application developer?

Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association



--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to