I'm guilty of this just like the rest, DAO is a pattern which can be used
within entity beans or with other mapping technologies. A comparison
between entity beans, and JDO or other O/R mapping tools is more interesting
to me.
>
>> Our architecture had a workaround to use a session bean and plain
>> sql when a lot of "rows" needed to be loaded from the database. The
>> workaround outperformed the entity beans by a considerable factor.
>
> uh but that is a common pattern i would think. loading n rows from the
> db via ejbFindByXXX results in at least n+1 queries to the DB (1 to
> find the primary keys, n to instantiate the beans). this is clearly
> inferior to using a single query and putting the resultset into DAO's
> or whatever you might call them.
>
Two issues, one is that smart CMP implementations do all the SQL in the
finder method so they are O(1) for N beans. The second issue is that in an
environment where some of the data can be cached you can also reduce the N+1
to something smaller. With BMP it is considerably more difficult to solve
the N+1 problem in the absence of caching benefits. Of course how often are
you actually in a situation where you can cache the entity beans/unshared?
For me I think the issue is tools. If I had an EJB Container with good
tools for mapping my CMP Objects and efficient SQL under the covers then the
fact that it's a reasonably well adopted standard might push me towards
using that technology over a more niche player like a proprietary mapper or
JDO.
As an example, look at how successful Java has been when it clearly will not
outperform well optimized C/C++ code. We all need systems to go fast, but
is that always the #1 criteria?
Cheers
Jay
===========================================================================
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".
