This looks good, but I have just one question:
How does this model deal with relationships between beans?
Business logic in SampleBeanLogic might want to use some
other bean, but cannot directly reference the other bean and has
to go through the EJBObject wrapping the other bean. Idealy you
want to keep that out of the SampleBeanLogic class and have that
down in the SampleBean class. Also, if you use a mapping tool with
BMP, it will generate code for this.
Should the SampleBeanHome have a create method taking a SampleData object
as an argument? Also, since SamplePK probably contains a subset of the
attributes of SampleData should SampleData extend SamplePK?
Also, SampleBeanLogic should not directly implement the remote interface
(Sample), I like the idea of a SampleBusiness interface better.
Frank Sauer
The Technical Resource Connection
mailto:[EMAIL PROTECTED]
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of James Cook
Sent: Wednesday, July 21, 1999 4:54 PM
To: [EMAIL PROTECTED]
Subject: Re: fat getter/setters versus get/set with all data
I've thought of doing something like this, but backed off because I wasn't
sure how an EJBServer would support container managed persistence (CMP) with
this approach. This topic is also an extension to the list-thread: "generic
EJB thoughts"
I finally came up with a hierarchy that seems to work well, although I
haven't tested it yet. Set your email viewer to non-proportional fonts and
the diagram below will make much more sense (It's hard to draw UML with
ASCII:
+--------------+ implements +----------------+
| EntityBean | <- - - - - - - - | BaseEntityBean |
+--------------+ +----------------+
| ejbLoad(){} |
| ejbStore(){} |
+--------------+ +----------------+
| Sample | <-------+ ^
+--------------+ +------------+ | extends
| |
+--------------+ contains +--------------------------+
| SampleData | <--------------- | SampleBeanLogic |
+--------------+ +--------------------------+
| | SampleData data |
| implements +--------------------------+
V | SampleData getData() |
+--------------+ | void setData(SampleData) |
| Serializable | +--------------------------+
+--------------+ ^
^ | extends
| implements |
| +---------------+
+--------------+ | SampleBean |
| SamplePK | +---------------+
+--------------+ | ejbCreate(id) |
| ejbLoad() |
| etc... |
+---------------+
BaseEntityBean: responsible for a null implementation of EntityBean
interface. I actually have code in this class that can optionally printout
the time and method that is executing. That gives me some ability to view
when the container calls my ejbLoad, ejbStore, etc. methods. Also
setEntityContext and unsetEntityContext are implemented here.
Sample: remote interface that declares the business methods available.
SampleBeanLogic: only an implementation of the Remote interface goes in
here. This looks very good as there is no EJB specific code, only business
logic. There is also an attribute of type, SampleData which is a reference
to the object holding the business attributes. I implement the setData and
getData methods that pass the business attributes with a high level of
granularity. This satisfies the purpose that started these threads and
countless other threads on granularity.
SampleData: a class that contains business attributes. Under certain
circumstances, when a Java client is involved, these classes could contain
field-level validation methods if the EJB server supports pass-by-value.
This simple validation will be very useful on the GUI client, and should
save much network traffic.
SampleBean: for CMP beans, this is where the implementation of ejbCreate
will go, and that's about it. For BMP, all of the appropriate persistence
methods are implemented. This is very good separation since only database
code will exist here in most circumstances.
SamplePK: hasn't changed.
I would also advocate the business/remote separation pattern that has been
kicked around here. It creates yet another class, but for die-hard (aka
Glutteous Clenchimus) OOPists you can separate the Sample class into
SampleBusiness that is extended by Sample (which extends EJBObject). The
SampleBeanLogic then could implement SampleBusiness to ensure that the
appropriate classes were implemented at compile time.
Could this be the holy grail of EJB design? Hardly, but it's worth
investigating. There have been other posts that mention a name-value pair or
hashtable approach to passing data to and from the client. I suppose
name-value pairs as long as they were stored in an array to achieve maximum
language/platform independence. XML would work as well. Personally, I think
the SampleData class should perform better, require much less coding, and in
the Java-Java world it should allow some validation to take place on the
client.
The first problem that comes to mind with this approach involves CMP. With
the data attributes hidden behind an object reference (sampleData), how
could these Containers know which fields to persist? For those using OODBMS,
I suppose you would persist the sampleData object...problem solved. For the
other 80%(?) of us, I think we're stuck, until the Containers get just a
tiny fraction of a hair smarter and allow us to specify persistent
attributes as "sampleData.firstName".
Secondly, I know some containers that can't even handle the business/remote
separation pattern I mentioned earlier, let alone handle the separation of
the EntityBean implementation described above.
I'm not sure if these shortcomings are our fault. I think we should be able
to change our EJB component design to suit us, as long as it adheres to the
spec. I think the container vendors should look upon this pattern as a
feature request. Some vendors may be able to support the pattern now. If
this is the case, I would look forward to hearing about it. If not, what are
the challenges in implementing such a design?
Now if we could convice Jim, Ian, the Valto folks or others to put up some
concrete diagrams describing the ever ellusive "EntityBean as Collections"
and the "Definitive Guide to What is a Dependent Object, and How Does One
Use Them?" all of life's mysteries would be solved. Then we could start
coding some applications for a change ;-)
jim
----- Original Message -----
From: Terran Vigil <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 21, 1999 1:46 PM
Subject: fat getter/setters versus get/set with all data
> For performance reasons, I've been thinking about replacing my Entity Bean
> getter and setter methods with fat .extractData() and .setData() methods.
At
> the same time, I would create a serializable container class that would
wrap
> only the properties of the EntityBean. This would:
>
> - eliminate a plethora of getter and setter methods that clients can't
call
> anyway (I'm using the "SessionBean wraps EntityBean" model).
>
> - Prevent the EJB container from calling ejbStore() multiple times.
> Actually, I guess this is only a problem if the EntityBean is called
without
> a calling transaction.
>
> - Provide a data class for returning data to client since we aren't going
to
> pass EJBObjects to client.
>
> What does everyone think? Anyone else doing this?
>
> Terran
>
>
===========================================================================
> 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".
===========================================================================
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".
