Entity beans & business logic...
by Dan Pilone
So this is a little heavy for my first blog entry, but I figured I'd start out with something that at least sounded interesting before I resorted to "What I installed on my computer today" style entries. On my current project we're dealing extensively with J2EE Entity beans. There are some legacy ones using BMP that we're moving to CMP and some new ones that are being written CMP style right off the bat. So, this gets me thinking about where the business rules live...
Here's the situation: we have a set of legacy BMP entity beans with business rule validation in the setters and getters. We need to move those to CMP beans at some point the future. I'm aware of the Antipatterns book about subclassing the bean to allow easy migration, etc. That's not what this is about. This is about how to validate the data moving in and out of the bean in the context of the larger system.
Obviously once we move to CMP we end up with abstract setters and getters, so that's not going to work. I don't feel like the logic should be there in the first place, but that's a different story.
Then there's the option of putting it in ejbStore, but I feel like that's too late to really do anything useful (other than punting on the commit) and really makes me feel... dirty.
So, move it up to the next level, start building a services based approach. A clean, subsystem like API that can enforce business rules; once everything checks out, persist the bean. However, this seems to push back against the idea of using local interfaces and hitting the entity beans directly in favor of BO's or DTO's or whatever you want to call them.
We've chosen to go the subsystem route with BO's coming in and out of the APIs. That gives us a cleaner layering where the subsystems (session beans) handle validating and persisting their information using entity beans but the rest of the system passes BOs around.
|Have you considered using JBoss Rules to encapsulate the Business logic (as per this O'Reilly Article)?|
Using ejbStore is very problematic - the container is free to call this at any time, multiple times, during the course of the transaction - and it does!
We implemented our own mechanism for keeping track of dirty beans involved in a transaction and called the relevant validation method on each dirty bean once and only once when the transaction was ready to commit. The downside is we've done some extra work that the container is already doing, but we're in complete control and at the same time no-one can write code that persists invalid data.