Confusion with BusinessObject implementations 2004-08-19 - By Ray Ye
Back
Hi all,
I think the major difference between the two approaches is just as Robert
described, the frist one is using Abstract Factory/Factory pattern, the
second one is using DAO pattern, and there is really no which is right or
wrong. Each of them will work under some cirumstances.
However, we are discussing the problem under the J2EE environment, and
leveraging on container technology, and container is really the process
here, and it already provides the factory methods such as
create/remove/find etc., so it makes more sense to me that DAO which
shields the implementation detail from business object is the way to go.
Cheers,
Ray
On Thu, 19 Aug 2004 08:53:47 -0400, Robert Taylor <rtaylor@(protected)>
wrote:
>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)
====================================================================
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)
|
|
