Large finders on entity beans refactored 2003-09-16 - By Stefan Frank
Back
yeah, i recently thought, that this is actually a description of an
anti-pattern. It is mostly a pattern that tries to navigate around some
problems in the early implementations of the specification - for
Bean-Managed Persistence, using a finder for a large-result-Set brings
your whole application to a halt, as it results in (at worst) n+1
queries to the db , with n being the size of your result-set. But
performance tests with cmp (eg.
http://www.amazon.com/exec/obidos/tg/detail/-/1904284000/qid=1063717930/sr=8-1
/ref=sr_8_1/103-9118234-5330209?v=glance&s=books&n=507846)
showed no difference between using a Session bean for doing a jdbc-query
and instantiating objects for the Result or using a finder on
CMP-EntityBeans. So, to me the Idea that EntityBeans are "slow" or
"heavy" is a myth from early implementations. Therefore from my point of
view, this pattern addresses a performance-issue that has long since
gone away: And it does so on the cost of breaking the encapsulation of
your Data-Store. I've seen far too many applications that have parallel
DAO's accessing the Database using jdbc *and* EntityBeans - resulting in
2 ways into the Database...
cheers
stf
Moore, Gary wrote:
> Katz,
>
> My understanding for this warning is that the finder methods return
> a collection of remote interfaces, this can be a huge performance and
> resource issue if the finder method returns a large number or results
> from persistent storage.
>
> You are correct, this can pose a reusability issue. To minimize
> this, I use the DAO pattern and if I choose Entity beans, I would
> delegate the data access to the DAO.
>
> Just my $0.02
> Gary
>
> -- --Original Message-- --
> *From:* Katz Guy [mailto:Guy_Katz@(protected)]
> *Sent:* Sunday, September 14, 2003 1:42 AM
> *To:* J2EEPATTERNS-INTEREST@(protected)
> *Subject:* Large finders on entity beans refactored
>
> Hi;
> Going through the core patterns book.
> There is a bad practice dedicated to not using finder methods when
> large result is expected but use a DAO instead.
> My understanding is that the authors want to have a 'dual interface'
> for access to the same data, Modeling the data itself as entity
> beans yet using DAO for the search. Is this correct?
>
> If so, wouldn't this be in contrast to resusability? Also, isnt this
> a good place to put your money on vendor container optimiations?
>
> *__ ____ ____ ____ _____*
> *Guy Katz*
> *Software Architect, CAP-IFS*
> *Comverse*
> *guy.katz@(protected)*
> *+972 3 7663686*
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
> http://java.sun.com/blueprints/corej2eepatterns List Archive:
> http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
> listserv@(protected)
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
> http://java.sun.com/blueprints/corej2eepatterns List Archive:
> http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
> listserv@(protected)
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
