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".
