Dale,
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. Was it Steve McConnel who said
'a good programmer is someone who knows he is stupid' or something like
that.
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.
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.
William Louth
Inprise
www.inprise.com/appserver
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.
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Dale V. Georg
Sent: Wednesday, August 30, 2000 9:34 AM
To: [EMAIL PROTECTED]
Subject: Re: which of these should be an entity bean?
William Louth wrote:
>
> I do not understand why you still must go to the database through jdbc to
> construct a 'lite' object when you could use the standard approach of
> calling some bulk accessor on the entity (cmp) to return the 'lite' object
> or code the session bean to create the 'lite' object from values returned
by
> calls on the remote interface of the entity bean. This will lead to
> significant code reduction, performance improvement........
>
> William Louth
> Inprise
> www.inprise.com/appserver/
>
I'm not sure I follow you. If you called a bulk accessor on a CMP
entity, that's going to create all of the Entity Beans, from which you
would then have to extract the lite objects to return. One of the
things we want to avoid is creating the entire bean unnecessarily,
particularly if the Entity Bean is a fairly heavy object and/or if there
are a lot of them in the system. I think our approach is more
performant because we only create what we need when we need it.
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".
