Dave,
i like this idea for re-usable data objects (be they Session Beans or DAO)
with some qualification. The questions you raised:
>>1) What is the overhead of instantiation vs an in-memory inter bean call
I'd expect this would vary from container to container. The interesting
thing is that I gather that some containers capture the remote call and, if
they know the call can be satisfied locally, turn it into a local call,
saving some network overheads. I still think that object creation and
instantiation would be faster than using Session Beans even if the SB's are
pooled but that's not on the basis of any container experience. Does anyone
know what the costs are at container level ? <vendor> </vendor> responses
very welcome !!
>>2) Would DAO be available directly from a client source? No, you would have
>>to facade anyways inside a session bean.
Obviously this would be a design guideline to reduce the network overheads
of SQL calls from client to server and to preserve MVC consistency.
The fact that we are discussing this fairly basic design aspect shows us
how immature the persistence part of the spec is. However it does present
another level of data access consistency when one wants to access data
without going through the overheads of using EBs. Actually this raises
another point. Often times we have to build coarse EBs to encapsulate a
business object eg. Order (and it dependent OrderItems). Using DAO/Session
Beans to encapsulate the logic means that if we needed to we might be able
to access dependents within an EB without having to go to the cost of
instantiating the EB just to get to a dependent. This could be good or bad.
If the application is built assuming Commit Option A then we are badly
subverting the spec with potential to cause data integrity problems. Anyone
got any comments ?
cheers,
eddie
========
At 07:28 18/09/00 -0400, you wrote:
>I mean, why have inline SQL in the entity bean, or even helper classes which
>manage the interaction with the RDBMS when you could have a session bean do
>the same. For instance, the session bean would have insert(), delete(),
>select() and update() methods. Then you have
>
>session bean facade --> entity --> data access session.
>
>Now you can use the same session bean to do lookups, result set listing etc
>and use the same logic from your entity bean.
Snipped..
>>1) What is the overhead of instantiation vs an in-memory inter bean call
>>2) Would DAO be available directly from a client source? No, you would have
>>o facade anyways inside a session bean.
>Dave Wolf
===========================================================================
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".
