Dale,
I was not implying that you alone are stupid. I was talking about
everybody - just started my biggest war yet. The statement is used as a
reminder to us that the more we write they more likely we will create bugs
along with many other things. Its what you say to yourself before putting
your programmers hat on. It applies to many things include human computer
interaction design.
I will reply to the rest of your email in my next post. I am sorry if I
offended you this was not my intention.
William Louth
Inprise
www.inprise.com/appserver
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Dale V. Georg
Sent: Thursday, August 31, 2000 9:49 AM
To: [EMAIL PROTECTED]
Subject: Re: which of these should be an entity bean?
> I think I have already answered this is a previous email. What you are
> advocating is spreading the persistent logic all over your system instead
of
> using entity beans correctly? Increasing your coding leading to bigger
> maintenance headaches and most likely bugs.
That's absolutely not what I am advocating. What I said in one of my
earlier mails was that if you are using BMP, you are writing all of the
persistence logic yourself, and the best way to do it is to encapsulate
the persistence logic in a series of helper classes, specifically for
the reason of avoiding duplicate code. I'll give you some more details
on the approach we are using:
Each of our Entity Bean classes inherits from a "lite" class, as we
discussed earlier. So we might have, for example, an XYZLite and an XYZ
that extends XYZLite. We then also have two classes that we call "data
translators", one called XYZLiteDT which knows how to persist XYZLite,
and one called XYZDT which extends XYZLiteDT and knows how to persist
the additional attributes of XYZ. By taking this approach, the
persistence logic is tightly encapsulated in two related classes (it is
not spread all over the system) and changes to the persistence logic are
easy to make and easy to debug. Additionally, we have the capability to
quickly access a list of lite objects via a Session Bean talking to an
XYZLiteDT object.
Please keep in mind that I prefaced this whole explanation by saying "if
you are using BMP". I'm not saying that this approach is any better or
worse than a CMP approach; what I am saying is that if you are using BMP
(for whatever reason), then I think that this is a very simple and
flexible approach. Do you agree or do you see problems? If you see
problems, please let me know; I'm more than willing to listen.
> Was it Steve McConnel who said 'a good programmer is someone who knows he
is stupid' or
> something like that.
I don't know. My belief is that a good programmer is (in part) someone
who has an open mind and can see that there are usually many solutions
to a problem, each of which has a series of pros and cons that need to
be weighed in making a design decision. Very rarely is any solution
100% perfect with no downsides to it, and even more rarely is any
solution perfectly suited to all problems. With that in mind, can we
have a discussion of the pros and cons of our approaches without your
implications that I'm stupid? Thanks.
> All this for what? Peformance. Hmmm. OK what I am advocating is using
entity
> beans but I am probably in a better position than most in this regard. We
> have done some performance tests ourselves and in most cases our test runs
> with cmp entity beans match and even beat those of the session beans +
jdbc
> figures. We have built in many optimizatons into our cmp engine to give
you
> your cake and eat it.
Having not used CMP, and having not used Inprise, I can't really argue
one way or the other on this, but I have to admit to a degree of
skepticism. Under some conditions, I'm sure you're right; I'm sure that
with a highly-optimized CMP engine, you could query and populate a
collection of Entity Beans faster than you could query and instantiate
those same objects from a Session Bean. But remember that for listing
purposes, we only need a couple basic attributes, not the entire bean,
to be instantiated. So, the Session Bean is instantiating n "lite"
objects, while the CMP engine is populating n full-fledged Entity
Beans. As you look at increasingly complex Entity Beans, at a certain
point the "Session Bean gets lite objects" approach is bound to be
faster.
> So let me restate things: If you are using the Inprise Application Server
> 4.1 or some other container which provides a proper cmp engine and good
> performing middleware then you do not always have to resort to using
session
> beans + jdbc for listing behaviour. You have a second option with leads to
a
> greener and cleaner world.
> Its strange that one of the implicit goals behind EJB was if your vendors
> container was not up to it that you could easily move to another one. How
> many times have I heard "I would like to design and write my system this
> way but because of ...... I am forced to do it this way while killing any
> chance of future movement". We still have some way to go but its fun being
> on board; I am not getting off just yet.
Admittedly, in an ideal world, CMP is a cleaner approach because you
avoid writing all of the persistence logic that you have to write with
BMP. My feeling, though, is that CMP really has not matured enough at
this stage. Look, for example, at the extensive changes to CMP in EJB
2.0, or at the fact that there is so much room for vendor-specific
features in the CMP engine. As you say, it makes designing your
application in most optimal way difficult, while still remaining
vendor-neutral. As with most everything in computing, it is all a
question of trade-offs. In our particular case, vendor-neutrality is a
high priority, so we take advantage of nothing that isn't in the spec.
That's why we're sticking with BMP until the specs on CMP mature some
more and become more flexible. Incidentally, encapsulating all of our
persistence logic into separate data translator classes also means that
there is no JDBC code directly written in our Entity Beans, which
positions us nicely for moving to CMP at a future date should we choose
to do so.
> PS: The container does not necessarily need to 'create all those entity
> beans'. What about the pool concept mentioned in the specification? All we
> need to do is load the state from the db into a read made instance.
True; a bad choice of words on my part. The instances are already
pooled, but they are essentially "shells" waiting to be populated.
Again, it comes down to how complex the Entity Beans are; if they only
have a few attributes, you probably don't gain much from the lite object
approach. But if they have lots of attributes, possibly with many
complex dependent objects as well, then populating those pooled
instances with all that data which isn't even currently needed may be
more work than it is worth.
Dale
================================
Dale V. Georg
Technical Manager
Indus Consultancy Services
[EMAIL PROTECTED]
(201) 261-3100 x229
================================
===========================================================================
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".
