 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Tomcat - JSP/Servlet container | | Struts - A MVC web framework | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | JSP - A mailing list about Java Server Pages specification and reference | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | |
Struts & Hibernate
|
|
|
| | | Confusion with BusinessObject implementations | Confusion with BusinessObject implementations 2004-08-19 - By Dhiren Mehta
Back
Hi,
I haven't gone thru this design pattern in this book, but what you
written that the book says "BusinessObjects encapsulate and manage
business data, behavior and persistence." Makes sense. In my experience
(as architect) I have implemented business objects in that does what is
stated above.
The business object (or called smart business objects) should expose
methods like persist() and static retrieve(id); these methods should
call appropriate persistent layer methods to retrieve / persist itself.
Doing so considerably reduces the code in the session beans / helper
classes. If logic to retrieve/persist is in session bean and if a
business object is used in several usecase flows then the code (which is
about few lines) to call the appropriate methods to retrieve/persist
these objects will be repeated at several places and will have to also
repeat the code to handle failures, however if such code is encapsulated
in the BOs then the session bean simply calls BO.retrieve(id) or
BO.persist and the session bean can focus on business flow
implementation rather than object management.
Dhiren
-- --Original Message-- --
From: An interest list for Sun Java Center J2EE Pattern Catalog
[mailto:J2EEPATTERNS-INTEREST@(protected)] On Behalf Of Robert Taylor
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)
===================================================================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)
|
|
|
