I would like to expand on a concept the was introduced here by Tobias
Dezulian in the "generic EJB thoughts" thread. It seemed that a couple
respondents whom I have enjoyed reading here were highly enthusiastic about
Tobias's concept, and I wanted to find out more.
Concept
=======
Separate an EJB into logical layers that would allow some reuse of common
business functions. This approach may also provide further encapsulation of
data access, business logic, and core functionality.
Rickard mentioned that he had considered the breakup of a bean to consist of
4 levels. I wanted to mention what I was thinking and see if others have any
input.
Level 1: Generic code necessary in all beans.
I would imagine that this could be a superclass that consists of some
concurrency control to keep track of a bean properties' original values. In
the case of BMP, these values could be compared against the database to
determine if user modified fields had changed since the record was retrieved
from the database. We use a reflection class and a hashtable to automate
this process now. (Rickard may have intended this with his mention of "dirty
flag mgmt".)
Would it be possible to include debugging messages that correspond with the
SessionBean or EntityBean interface here, even though that interface is not
"truly implemented" in a higher layer? Could you still invoke
super.ejbPassivate() which is in class BeanLayer1, while in BeanLayer3? This
of course assumes that BeanLevel3 extends BeanLevel2 extends BeanLevel1.
Level2: Basic bean attributes.
This layer would serve as the object/struct that gets serialized to the
client allowing for a level of granularity above the "per attribute" level.
This layer should be written to allow multi-language clients to receive a
copy of the struct for client-side processing. Rickard mentions that this
layer would contain CMP fields, which it does.
Level 3: Implementation of Home interfaces. (extends home interface &
EJBHome)
Creation and Finder methods are implemented. For BMP this will involve the
communication required to persist the object, if any.
Level 4: Implementation of Remote interfaces. (extends remote interface &
EJBObject)
Business logic would go here. I am considering the separation of the Remote
interface from the Home because of the database access required for BMP is
not "pure" business logic, and could be moved to another layer.
Is this approach really obscure? Will it break most of the tools that the
App Servers are shipping? Is there other suggestions?
Please give your criticism freely and keep in mind that I haven't written a
substantial EJB bean yet, nor have I designed a system that relies on EJB.
There may be some grievous errors that I have overlooked. Please let me
know.
jim
===========================================================================
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".
