Confusion with BusinessObject implementations 2004-08-19 - By Bayarsaikhan VOLODYA (YAZ-ArGe)
Back
Hi all,
According to me, method 1 is always clear and plain.
as mohit says, if there is a new db technology, we should NOT modify our object
, also DAO interface is left unchanged. only we modify implementation of DAO
interface.
You make DAO interfaces by applying Abstract Factory for choosing which
technology you want to use.
-- --Original Message-- --
From: Keswani, Mohit [mailto:mohit.keswani@(protected)]
Sent: Thursday, August 19, 2004 3:05 PM
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)
|
|
