I like this idea, but is it required that the lowest level of the layering
heirarchy contain a null implementation of the Home and Remote interfaces?
The reason I ask, is we have a mechanism in place for aiding with
concurrency checks when it comes time to store object in database. This
class is now a superclass in our Factory implementation and we would like to
carry it over to EJB. We would prefer to extend this class and include the
null implementation of interfaces in the extended class.
jim
----- Original Message -----
From: Rickard �berg <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 08, 1999 11:09 AM
Subject: Re: generic EJB thoughts
Hey!
"Dezulian, Tobias" wrote:
> I've been developing an application which uses 5 entity bean types
> which only differ sleightly.
> Thoughts came up to design ONE generic entity bean
> and then upon creation shape it to serve different purposes
> and store itself to _its_ db table.
> Anybody tried something like this out yet ?
>
> An obvious way to achieve genericity would be to let all
> needed bean types inherit from some baseBean and
> add methods and attributes specific to this particular type.
> Is there more genericity possible ?
> Maybe even at runtime ?
This is a great idea. I've had ideas about splitting a bean up into 4
separate layers:
* The bottom layer is the most "generic" and contains all code that goes
into all beans (such as null impl of *Bean, dirty flag mgmt, etc.)
* Next is data layer which contains all CMP fields with get/set methods.
This should be generated from some metadata about the bean. I have tools
for this.
* Next is logic layer which contains the bean specific logic and code
* Next is BMP layer which is the (hopefully generated ) code for doing
database mgmt. This is null if container CMP is used.
Using this strategy should make it easier to develop and maintain beans.
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
