I like that approach a lot because:
1. It really separates data and data access from busines logic
2. It allows you to take advantage of CMP
3. All data access is done the same way throughout the code in a proven
manner.
The one issue that I see is that it seems natural to do data validation in
an entity bean as it seems silly to have two functions to setEmployeeName
for example. The way around this is to have the session bean (business
logic) that manages an entity bean do all data validation and then call the
set methods on the appropriate entity beans. Calls to a session bean can be
at a much higher level than set/get, such as
CreateEmployee("joe","33124","M"). Since the there will always be a session
bean to manage an entity bean, you can insure that data is valid before
calling the set methods. To the client of your session beans, the notion of
an underlying data store, then, becomes more transparent.
- Monica
-----Original Message-----
From: John Abbey [mailto:[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".
