Hi Janne,
I have several issues with entity beans, but this is not one of them.
If you check Chapter 4, under the section "Using Entity Beans", there is a
subsection titled "Business Logic in Entity Beans".
The entire section is worth reading, but I'll specifically quote:
"In general, the entity bean should contain business logic that is
self-contained to manage its data and its dependent objects' data."
You are correctly concerned about objects maintaining methods and data,
but careful analysis of objects and data is always required. In a very
brief review of your example, it appears to me that there are, at least,
User, Fines, and Book objects. There probably should be others to integrate
them properly, but the point is that Books don't really care about Users and
should only manage Book data. There might be some reference to a checked
out status and either a reference to the User or a means to determine the
User in a LibraryBook, but the User should handle its own methods and data.
Best,
Joe Sam
Joe Sam Shirah - http://www.conceptgo.com
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum: http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International? http://www.jguru.com/faq/I18N
Que Java400? http://www.jguru.com/faq/Java400
----- Original Message -----
From: "Janne Mattila" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 27, 2003 3:31 AM
Subject: EJB design patterns ruin decent object design?
> Hi,
>
> I've been reading some J2EE books, most importantly "core J2EE patterns",
and have been getting increasingly confused and also somewhat irritated by
some EJB design issues. Core J2EE patterns seems to support the view of not
having business logic in entity beans. Amongst others, refactorings "move
business logic to session" and "wrap entities with session" suggest this.
>
> This way, business logic related to use cases would be in different
methods in session beans, and entity beans role would be left as dumb
persistence mappers. To me this sounds rather unintuitive....isn't the point
of object oriented design to have the data and the related functions
(=business logic) in the same object?
>
> [1] For example, a case of some library application where we have a
concept of User and associated methods
>
> User.loanBook(Book book);
> User.payFines(int dollars);
>
> This is how I would probably associate the methods (of course loanBook()
could be also associated with the Book object, but that's not relevant). But
if the object design is done by the suggestions in the book, we have the
business logic methods in either one or several session beans [2]:
>
> BookLoanSessionBean.loanBookForUser(int userID, int bookID);
> PayFinesSessionBean.payFinesForUser(int userID, int dollars);
>
> Again, both methods could could be in the same session bean but I think
that's not relevant. Doesn't that approach sound rather more like functional
programming than object oriented? Methods are separated from the data?
Business logic which is clearly associated with a given object ends up
scattered through different session beans?
>
> Also, since CMP persistence is handled by the container, what is left in
the entity beans if the business logic is also removed?
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
