Designing BusinessObjects (again) [Was Confusion with BusinessObject impleme 2004-08-26 - By Robert Taylor
Back
Wow! David, thanks for the indepth response.
> Ah, but are you implying that these concepts were invented along with
> EJB?
Nope. Just an observation.
> 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).
I have to say I'm not familiar with the formal components of DDD; however,
based on the above definition, then in my case, I guess the DAO
implementation would be a Manager of sorts as I would expect it to handle
query, update, delete, and creation of data. I would also expect it to handle
caching issues.
UserManager is simply a layer on top of the DAO; responsible
for creating and deleting User objects as well as retrieving and restoring
them from the repository/data store. It provides logic to ensure that the state
of
the data is valid before creating, deleting, or finding a User.
User inherits from UserData and so becomes a layer on top of the DomainObject
providing intrinsic business logic for User. User maintains no reference
to UserManager but upon creation or restoration, UserManager is resposible for
populating User with the appropriate implementation of UserDAO so that User
can persist any updated data or lazily load any dependent objects.
UserData could be used as a TransferObject to propogate its state "up" to the
presentation layer.
> Exactly, and your Managers could map UserData objects to UserEJBs if you
> wanted to go the entity bean route.
Hmmmm. I think I have been so influenced by Rod Johnson on this issue that I
hadn't factored in EntityBeans into my design.
> Wrapping the UserData within a User could provide this functionality 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?
Well, User inherits the data attributes from UserData and does update
its own state, but doesn't delete itself. I've already explained my
reasoning here.
http://bellsouthpwp.net/r/o/robertkaren6465/pages/java/bo/
Thanks again for taking the time to read over my design questions.
robert
> -- --Original Message-- --
> From: An interest list for Sun Java Center J2EE Pattern Catalog
> [mailto:J2EEPATTERNS-INTEREST@(protected)]On Behalf Of Harkness, David
> Sent: Thursday, August 26, 2004 1:28 PM
> To: J2EEPATTERNS-INTEREST@(protected)
> Subject: Re: Designing BusinessObjects (again) [Was Confusion with
> BusinessObject implementations]
>
>
> 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)
>
====================================================================
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)
|
|
