Large finders on entity beans refactored 2003-09-18 - By Moore, Gary
Back
Alok,
As far as the advantages for using the DAO pattern with a BMP Entity
Bean, there are few.
The most notable advantage is, should you choose to convert from BMP
to CMP, you may have less refactoring if the data access code is
encapsulated in a DAO.
The other reasons may not necessarily be advantages, but just good
programming practices.
To name a few
1)Encapsulation of data access code (As you mentioned, only relevant
if you are performing the JDBC logic yourself, vs. the container handling it
for you).
2)Consistency, when it comes down to it, it is a good idea if you
have Session Bean logic which may be performing larger data set lookups to
utilize the same DAO pattern as does any BMP entity bean, especially when
dealing with the same business concepts.
Unfortunately, I do not have a lot of experience with Entity Beans.
In the earlier ejb specifications, it was not practical for even moderately
sized and well normalized data models. In addition, most container vendors I
was familiar with, seemed to poorly implement when it is appropriate to call
ejbLoad and ejbStore.
Great discussion though,
Gary
-- --Original Message-- --
From: Alok_Band [mailto:Alok_Band@(protected)]
Sent: Thursday, September 18, 2003 7:32 AM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Large finders on entity beans refactored
Hi,
If Entity Bean is CMP then DAO pattern can not be used.
What major advantages one gets by using Entity Bean with DAO pattern ?
If finder() method is returning data for only Viewing (Read only) then I
have following points to make,
1] If finder() method is used then container has overhead of making Remote
Objects, data is read for transaction i.e.Isolation Levels are considered.
2] If custom finder method is written then it can read data as read only
i.e. w/o considering isolation level. Also one can optmise SQL query like
fetch only few colums etc.
3] Usually finder() method returns data from multiple tables i.e. SQL
contains joins so I may have better control on optimization of finder SQL
query then using entity beans.
Please correct me if I am wrong...
Regards,
Alok
> -- --Original Message-- --
> From: Moore, Gary [SMTP:gmoore@(protected)]
> Sent: Tuesday, September 16, 2003 6:03 PM
> To: J2EEPATTERNS-INTEREST@(protected)
> Subject: Re: Large finders on entity beans refactored
>
> 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)
**************************************************************************
This email (including any attachments) is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or
distribution or forwarding of any or all of the contents in this message is
STRICTLY PROHIBITED. If you are not the intended recipient, please contact
the sender by email and delete all copies; your cooperation in this regard
is appreciated.
**************************************************************************
====================================================================
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)
|
|
