Designing BusinessObjects (again) [Was Confusion with BusinessObject impleme 2004-08-26 - By Harkness, David
Back
Hiya Robert,
I'm actually about to embark on this task from a different direction:
replacing all usage of EJBs (both session and entity) with Hibernate and
Spring. I would have gone that route from the start, but I joined the
project after those decisions had been made. It took a year to convince
management, but hey, better late than never, eh?
Regardless, the patterns are the same and apply equally well.
Robert Taylor penned
> Yes UserFactory is analogous to UserHome although I'm not trying to
> recreate EJB framework, just stealing some idioms :)
Ah, but are you implying that these concepts were invented along with
EJB?
> Like I said, to me it makes sense that creation and location for
> objects like User
> should be managed by an external entity; UserFactory. Also, after some
> reflection, I'm thinking that UserFactory should be changed to
> UserManager,
> as the user of "Factory" is in appropriate.
I like Manager as well as it permeats the culture. In Domain Driven
Design the Manager is separated into two classes: Repository
(query/read, update, delete) and Factory (create). It's sometimes common
to require several methods of creating a domain object (multiple
factories), while typically the other operations can be generic. If you
need that ability but use a single class, you end up either with methods
like
UserManager
- createNormalUser()
- createAdminUser()
Or
- createUser(type)
Okay, bad example since the "type" of user would likely just be a field.
But imagine a case where you have several subclasses of a particular
domain object. You could use the Strategy pattern to do this, but you'll
still require the above methods to choose the strategy to use. I'm still
torn, but I lean toward a single class.
And as you said, there's no need for a DAOFactory as this becomes
Spring's ApplicationContext. I'm getting some pushback about using
Spring, most likely because they still see it as a major container
infrastructure like the EJB container. More educating is in order. :)
> I believe this will scale to using EJB. All I should have to do is to
> place
> a SessionFacade in front of the ApplicationService which uses the
> BusinessObjects.
Exactly, and your Managers could map UserData objects to UserEJBs if you
wanted to go the entity bean route.
> In talking through this, I guess is feasable to remove User from the
> picture
> and just use UserManager which would just perform operations on
> UserData
> and would contain the appropriate persistence logic. It just seems
> more procedural
> than OO.
I've been thinking about this one from a different angle. Basically, I
want transactionality for clients without cloning every object when its
taken from a cache. What I'd like is to be able to hand out a User to
the client that wraps the cached known good state of the UserData. This
User would have references to its Manager as yours does, but the main
reason is so that when a client calls a business method or setter that
modifies the data, it first ensures that it has a modifiable UserData.
The Manager (or likely a separate CacheManager) would check if UserData
is the single cached copy or is already modifiable. If it's the cached
copy, it would clone it, add it to a UnitOfWork, and put it into the
User. Now all further business methods would modify the client-scoped
UserData. When the changes are committed, they are first applied to the
data layer and then pushed back into the cache.
Wrapping the UserData within a User could provide this funcationality as
well as give you the ability to do user.save() and user.delete(). Of
course, since a User doesn't delete itself, is that really more OO?
--
David Harkness Sony Pictures Digital
Sr. Software Engineer 310.482.4756 dharkness@(protected)
Those who judge the value of advice by its source
will at once dismiss the best and follow the worst.
===================================================================Companion
Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
