John,
The question you have to answer for yourself is whether Entity Beans are
domain objects or not. It appears you have domain object behavior combinded
with your services layer (i.e. your session beans). We are choosing to use
Session Beans stricly as service facades for clients, adapting between the
domain layer and application layer. Session Beans are our transaction
control and use case service layer...
There is a collection or related topics at the Portland pattern repository.
See http://www.c2.com/cgi/wiki?EjbRoadmap.
In particular there is a thread on Entity Beans, see:
http://www.c2.com/cgi/wiki?HowToUseEntityBeans.
>From there you will see:
http://www.c2.com/cgi/wiki?EntityBeansAsDataGateways, which is what you are
proposing. At GemStone we are leaning toward:
http://www.c2.com/cgi/wiki?EntityBeansAsDomainObjectGraphs, and treating
EntityBeans as the root of a cluster of related domain objects.
I can't see we absolutely know we are right. We need to see more results
from industry deployments before the fat lady sings!
Some things to be concerned with in general:
- Beware of finders returning large result sets. EntityBeans life cycle
rules and finder behavior make this pretty inefficient.
- Beware of remoting entity beans to your client. Lots of fine grained
remote references to EntityBeans will kill your performance and scalability.
-Chris.
> -----Original Message-----
> From: John Abbey [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, January 06, 2000 1:55 PM
> To: [EMAIL PROTECTED]
> Subject: Entity Beans: Approach Validation
>
> I've done some development of Session EJB components that have various
> services (i.e. Error management, object relationship management). In
> addition to the basic "business" services, the EJBs had methods to
> access/update the object's data. This was done manually with our own SQL.
> The reason we chose Session beans was because of the immaturity of entity
> support within the Application server that we used for development.
>
> The tool we're using now supports Entity beans and I was wondering if the
> following architecture is sound and if any of people within this community
> have used a similar approach.
>
> The methods that I originally coded manually in my Session beans to
> perform data access/update could be changed to used very thin Entity
> "Data" beans. Basically I would instantiate the Session bean and when I
> wanted to retrieve data from it, I would simply use the object's
> designated Entity "Data" bean to access the data. In addition, changes to
> the object could occur within the Session bean, be validated, and if
> validation was successful, transfer the update logic to the object's
> designated Entity bean.
>
> This approach would allow me to used my existing Session objects for real
> business functionality, while data access/update could be offloaded (using
> CMP) to Entity beans.
>
> To clarify, this is what each component would be responsible for.
>
> Session Beans
> -------------
> Business Methods
> Object Validation
> Attribute Validation
> Object relationship management
> Business Error Services
>
> Entity Beans
> -----------
> Thin DB access layer used by Session Business Objects
>
> Thanks so much for any input. I look forward to hearing from all of you.
>
> John Abbey, AMS eCustomer
>
> ==========================================================================
> =
> 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".
===========================================================================
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".
