Francis Pouatcha wrote:
> Hi Dave,
>
> <snip>
> 2. Entity beans do some kind of usefull data caching when they are well
> modelled. The more common situation is to use entity beans that
> represent real live actors (Employee, BusinessPartner, Customer) or
> object belonging to them (Contract). This kind of entity bean are often
> <snip>
I have been using actors as sessions and the objects that they use as entity. They
have been working great and logical to me. Session Beans should be people and the
Entity Beans should be the object that they work on. In an Enterprise environment,
it is less likely that you will take care of the system that you design. It will
even be more less likely that you will develop ancillary components to your core
project, so having an actor name as a session bean gives room for growth. Plus, it
provides a common place for logic. I.E. the same people in a company that you
would go to for a certain function, would have a "bean" that represents them to
provide information. I understand your idea, of not doing Customer, and Employee
as a session which makes sense. I just wanted to shed light on some of the things
that I do, that actors can possibly be session beans. I guess to put it into
laymans, as far as actors are concerned, The actors you work on should be entity,
and the actors you work with should be sessions. <hehe, sounds kinky>. I have
some rinky-dinky egs below.
Session Entities
------------- --------------
Registrar Employee
Payroll Employee
Time
Broker Shares
Market
--
Dan Hinojosa
Java & Lotus Notes Consultant
Java Certified Programmer
P.O. Box 4675
Albuquerque, NM 87196-4675
Telephone: (505) 262-0911
Email: [EMAIL PROTECTED]
WWW: http://www.digitalpriest.com
===========================================================================
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".
