John,
I understand that you may wish to leverage existing code.
Personally however I believe that business logic and data
for an entity should not be separated.
This to me is the more OO approach.
Using Entity bean's as you are suggesting seems like it
should lead to overcomplicated code in your 'Data' session
beans. Moving the functionality that currently resides in
these Session bean to the new Entity beans shouldn't
be 'too' complicated and the end result ought to be a lot cleaner
and more maintainable.
There are plenty of situations where it makes sense to have
business functionality in session beans. However where that business
functionality is clearly part of a particular entity I don't think it
makes sense.
I'm not sure what you mean by Object Validation
To be clear, I think
Session Beans
-------------
??Object Validation
Some Object relationship management
Other Services (Business Error etc)
Entity Beans
-----------
Entity relationships
Business Methods
Attribute Validation
Alan
John Abbey wrote:
> 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".
