Confusion with BusinessObject implementations 2004-08-19 - By Robert Taylor
Back
I agree, but I use the same Strategy in both methods.
The DAO is an interface and its implementation can change
without impacting any of its clients.
My main question was should the BusinessObject itself encapsulate
the management of its own persistence (via delegation to DAO)
or should the process of persistence happen external to it.
It appears that you agree with this approach where as Bayarsaikhan
seems to agree with METHOD 1.
This is the type of dichotomy I am running into, I guess its just
a matter of taste.
robert
> -- --Original Message-- --
> From: An interest list for Sun Java Center J2EE Pattern Catalog
> [mailto:J2EEPATTERNS-INTEREST@(protected)]On Behalf Of Keswani, Mohit
> Sent: Thursday, August 19, 2004 8:05 AM
> To: J2EEPATTERNS-INTEREST@(protected)
> Subject: Re: Confusion with BusinessObject implementations
>
>
> Robert,
>
> METHOD II is the correct way because you can change your DAO implementation
> anytime.
> For example, say your system currently uses simple POJO DAO's. Now if
> tomorrow there is a new technology like Hibernate that you want to use then
> your DAO will change, but the DAO interfaces remain same and there is no
> change in business layer.
>
> Regards
> Mohit
>
> -- --Original Message-- --
> From: Robert Taylor [mailto:rtaylor@(protected)]
> Sent: Thursday, August 19, 2004 5:13 PM
> To: J2EEPATTERNS-INTEREST@(protected)
> Subject: Re: Confusion with BusinessObject implementations
>
> So it seems like you would subscribe to METHOD 2 implementation and that the
> BusinessObject would use (have as a data member) the appropriate DAO to
> manage (persist and access) its state.
>
> robert
>
>
>
>
> > -- --Original Message-- --
> > From: An interest list for Sun Java Center J2EE Pattern Catalog
> > [mailto:J2EEPATTERNS-INTEREST@(protected)]On Behalf Of Keswani, Mohit
> > Sent: Thursday, August 19, 2004 12:04 AM
> > To: J2EEPATTERNS-INTEREST@(protected)
> > Subject: Re: Confusion with BusinessObject implementations
> >
> >
> > Hi Robert,
> >
> > "BusinessObjects encapsulate and manage business data, behavior and
> > persistence"
> > The statement implies that persistence is achieved not in Business
> > Layer but by using DAO layer.
> > The word which is tricky here is "encapsulate and manage". So business
> > objects contain the logic to maintain data, behaviour and persistance
> > through DAO.
> >
> > I hope this clears your doubt.
> >
> > Regards
> > Mohit Keswani
> >
> > -- --Original Message-- --
> > From: Robert Taylor [mailto:rtaylor@(protected)]
> > Sent: Thursday, August 19, 2004 5:55 AM
> > To: J2EEPATTERNS-INTEREST@(protected)
> > Subject: Confusion with BusinessObject implementations
> >
> > Greetings,
> >
> > I've been reading Core J2EE Patterns, Second Edition and for the most
> > part it has really been helpful in explaining the architectural
> > entities of the enterprise.
> >
> > However, after reading the section on the business tier and having
> > various discussions with other architects I'm confused about the
> > following passage on page 375 in the BusinessObject section (chapter 7).
> >
> > "BusinessObjects encapsulate and manage business data, behavior and
> > persistence."
> >
> > This seems to imply that the BusinessObject should contain methods
> > like create(), update(), delete(), and various finder methods for
> > managing its own persistence and data access along.
> >
> > This, however, does not seem to be the concensus when implementing
> > BusinessObjects.
> >
> > Most architects manage persistence extrinsically to the BusinessObject
> > itself.
> > That is, they use the appropriate DataAccessObject to persist and
> > access BusinessObjects; usually within some type of ApplicationService
> > or ServiceFacade.
> >
> > For example:
> >
> > // Creating a new account METHOD 1
> > Account account = // populate account BusinessObject AccountDAO
> > accountDAO = // get an instance of AccountDAO
> > accountDAO.create(account);
> >
> >
> > as opposed to...
> >
> > // Creating a new account METHOD 2
> > Account account = // populate account BusinessObject account.create();
> > // create a new account delegating persistence to AccountDAO
> >
> >
> >
> > It seems like METHOD 2 is more OO but requires the BusinessObject to
> > become a facade to the DAO, where as METHOD 1 seems more procedural
> > but has a clearer architectural separation of responsibility.
> >
> >
> > Can anyone give me some pros and cons on the above two approaches?
> > Is one better than the other?
> >
> > robert
> >
> > ====================================================================
> > 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)
> >
> >
> > Our name has changed. Please update your address book to the following
> format: "recipient@(protected)".
> >
> > This message contains information that may be privileged or
> > confidential and is the property of the Capgemini Group. It is
> > intended only for the person to whom it is addressed. If you are not
> > the intended recipient, you are not authorized to read, print, retain,
> copy, disseminate, distribute, or use this message or any part thereof. If
> you receive this message in error, please notify the sender immediately and
> delete all copies of this message.
> >
> > ====================================================================
> > 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)
>
>
> Our name has changed. Please update your address book to the following
format: "recipient@(protected)".
>
> This message contains information that may be privileged or confidential and
is the property of the Capgemini Group. It
> is intended only for the person to whom it is addressed. If you are not the
intended recipient, you are not authorized
> to read, print, retain, copy, disseminate, distribute, or use this message
or any part thereof. If you receive this
> message in error, please notify the sender immediately and delete all copies
of this message.
>
> ====================================================================
> 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)
|
|
