Guillaume Rousse wrote:
> In a well separated layer design, applicative layer should be independant of
> persistance layer. So the use of a OODBMS or A RDBMS should not influate
> modeling in the application layer.
> Entity beans are clearly violating this separation rule.
This is incorrect. Please explain how entity beans violate this
separation. They may not be the best technology available for going to
an OODBMS, but they can certainly do it. Have I missed something?
> But from what i've
> understood so far, session beans were designed to model process rather than
> concept. Moreover, they have no persistance. So how can you use them to model
> real-world entities ?
I wouldn't in most cases if the real-world entities you're talking about
have state of their own. You're correct here.
But just because something exists in the real world and is an "entity"
in some sense of the word doesn't mean it can't be modelled as a session
bean. Think of real-world counterparts for a moment. Richard
Monson-Haefel's book has a great example (that's a little hard to
generalize, but that's not his fault). You have a CruiseShip with Rooms
and a Customer wants to buy a ticket. The session bean that implements
this process is called TravelAgent--that is, it models a real world
entity, but it does not contain any state of its own. The TravelAgent
bean calls the various entity beans to actually do the work and save
state.
Other examples of session beans (I'm going to start sounding like Peter
Coad) might be: HotelReservationAgent, Concierge, TestAdministrator,
ShippingClerk, Registrar (my personal favorite; that took me a while to
come up with), Dispatcher, RoutingAgent,
Finding these real-world counterparts can really help your design. **In
general, if you can identify a person or an office that organizes some
work before handing it off to some other person or office, that person
or office should be represented as a session bean.** The reason is that
the organizer rarely keeps state of his own, but does the "up front"
work that has to be done before it can be saved away.
Representing anything else as a session bean should be done for
performance benefits only (I'm being a bit dogmatic for brevity).
Again, dissenting opinions welcomed.
Cheers,
Laird
===========================================================================
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".
