DAO Design 2005-08-20 - By unmesh joshi
Back
Hi Richard,
I will be able to use Lazy Loading to avoid entire object graph to be loaded.
Thanks for the quick response. One more question I had was, Which of the
techniques is generally used? I think the second approach with lazy loading
should win over the first one. What do you think?
Thanks,
Unmesh
Richard Yee <ryee@(protected)> wrote:
Unmesh,
Can you still use the Lazy loading pattern to prevent the entire object graph
from being populated?
-Richard
At 10:47 AM 8/20/2005, you wrote:
Hi Richard,
Thanks for the response.
In case of deletes also, it is required to call update method. The idea is
Profile object itself will keep track of all the changes made, and update
method of Dao will iterate through Profile object to find out what things
changed and then make database changes.
Actually in our current project, we are accessing a different systems through
webservice call. So Dao is building XML instead of SQL query. Profile is built
with a webservice call to this system.
Richard Yee <ryee@(protected)> wrote:
You could use the second approach and reduce the overhead of loading the
objects by using LazyLoading. That way, if the phoneList or addressList is not
accessed, then it is not loaded from the database. I assume that a Profile is
populated using multiple queries to different tables. In you second scenario,
the profile object is only written to the database when the update(profile)
method is called. What happens when you want to delete an address or phone
object from the list? Does it get written to the database immediately or does
it still require an update(profile) call? If it happens immediately, then you
could have an addAddress() method that also writes to the database w/o calling
update(profile) and without loading the address list.
-Richard
At 04:51 AM 8/20/2005, you wrote:
Hi,
I have a question regarding design of DAO. In our project we are creating
customer profiles. We have modeled profile like this
class Profile {
Name name;
List<Address> addressList;
List <Phone> phoneList;
....
}
We have CRUD operations for Profile, Addresses, and Phones.
For crud operations, we have DAO facade like this
class ProfileDao {
void insertProfile(Profile profile);
void Profile getProfile(String profileId);
void addAddress(String profileId, Address a);
void addPhone(String profileId, Phone p);
void updateAddress(String addressId, Address a);
void updatePhone(String phoneId, Phone p);
void deleteAddress(String addressId);
void deletePhone(String phoneId);
..........
}
Client for this code will be like this.
class ProfileClient {
void testAddAddress() {
Address address = new Address("112 Fifth Street", "NJ", "US", "08857");
String profileId = getProfileIdentifier();
getProfileDao().update(profileId, address);
}
}
Instead of using Facade like this, I thought we could use it like following.
1. Clients will do all CRUD operations on Profile object itself.
2. All the classes will have isUpdated, isNew and isDeleted flag.
3. Dao will have just one update(Profile p) method.
4. Dao will check for updates and make queries accordingly
Dao will now become like this.
class ProfileDao {
void insertProfile(Profile profile);
void Profile getProfile(String profileId);
void update(Profile p);
}
Client for this code will be like this.
class ProfileClient {
void testAddAddress() {
Address address = new Address("112 Fifth Street", "NJ", "US", "08857");
Profile p = getProfile();
p.addAddress(address);
getProfileDao().update(profile);
}
}
This second approach looks cleaner, but the concern raised by my team mates
is that every time I need to add, update, delete a single address, I need to
load whole profile object in memory. This looks more like a "stateful"
implementation as opposed to "stateless" implementation of Dao Facade. If
Profile object is a huge one, then it can be a overkill to load the whole
object just to add/change one address. But I certainly dont like the facade
implementation. It does not allow me to do inserts/updates/deletes in batch. I
have to do operations one at a time. Secondly any object level validations or
business rules (Like Profile should have only one delivery address) are harder
to implement in facade approach. What is your opinion on this? Is this a
standard Domain Model vs Transaction Script issue?
====================================================================
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)
Start your day with Yahoo! - make it your home page ===========================
========================================= 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)
__ ____ ____ ____ ____ ____ ____ ____ ____ ____ __
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
====================================================================
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)
<DIV>Hi Richard,</DIV>
<DIV> </DIV>
<DIV>I will be able to use Lazy Loading to avoid entire object graph to be
loaded. Thanks for the quick response. One more question I had was, Which of
the techniques is generally used? I think the second approach with lazy
loading should win over the first one. What do you think?</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>Unmesh<BR><BR><B><I>Richard Yee <ryee@(protected)></I></B> wrote:<
/DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER
-LEFT: #1010ff 2px solid">Unmesh,<BR>Can you still use the Lazy loading pattern
to prevent the entire object graph from being populated?<BR><BR>-Richard<BR><BR
>At 10:47 AM 8/20/2005, you wrote:<BR>
<BLOCKQUOTE class=cite cite="" type="cite">Hi Richard, <BR>Thanks for the
response.<BR>In case of deletes also, it is required to call update
method. The idea is Profile object itself will keep track of all the changes
made, and update method of Dao will iterate through Profile object to find out
what things changed and then make database changes.<BR>Actually in our current
project, we are accessing a different systems through webservice call. So Dao
is building XML instead of SQL query. Profile is built with a webservice call
to this system.<BR><BR><B><I>Richard Yee <ryee@(protected)></I></B> wrote:
<BR>
<DL>
<DD>You could use the second approach and reduce the overhead of loading the
objects by using LazyLoading. That way, if the phoneList or addressList is not
accessed, then it is not loaded from the database. I assume that a Profile is
populated using multiple queries to different tables. In you second scenario,
the profile object is only written to the database when the update(profile)
method is called. What happens when you want to delete an address or phone
object from the list? Does it get written to the database immediately or does
it still require an update(profile) call? If it happens immediately, then you
could have an addAddress() method that also writes to the database w/o calling
update(profile) and without loading the address list.<BR><BR>
<DD>-Richard<BR><BR><BR><BR>
<DD>At 04:51 AM 8/20/2005, you wrote:<BR><BR>
<BLOCKQUOTE class=cite cite="" type="cite">
<DL>
<DD>Hi,<BR>
<DD>I have a question regarding design of DAO. In our project we are creating
customer profiles. We have modeled profile like this<BR>
<DD>class Profile {
<DD> Name name;
<DD> List<Address> addressList;
<DD> List <Phone> phoneList;
<DD> ....
<DD>}<BR>
<DD>We have CRUD operations for Profile, Addresses, and Phones.
<DD>For crud operations, we have DAO facade like this<BR>
<DD> class ProfileDao {
<DD> void insertProfile(Profile profile);
<DD> void Profile getProfile(String profileId);
<DD> void addAddress(String profileId, Address a);
<DD> void addPhone(String profileId, Phone p);
<DD> void updateAddress(String addressId, Address a);
<DD> void updatePhone(String phoneId, Phone p);
<DD> void deleteAddress(String addressId);
<DD> void deletePhone(String phoneId);
<DD> ..........
<DD>
<DD> }<BR><BR>
<DD> Client for this code will be like this.<BR>
<DD>
<DD> class ProfileClient {
<DD> void testAddAddress() {
<DD> Address address = new Address("112 Fifth Street", "NJ", "US", "08857"
);<BR>
<DD> String profileId = getProfileIdentifier();<BR>
<DD> getProfileDao().update(profileId, address);<BR>
<DD> }
<DD> } <BR>
<DD> Instead of using Facade like this, I thought we could use it like
following.<BR>
<DD> 1. Clients will do all CRUD operations on Profile object itself.
<DD> 2. All the classes will have isUpdated, isNew and isDeleted flag.
<DD> 3. Dao will have just one update(Profile p) method.
<DD> 4. Dao will check for updates and make queries accordingly<BR>
<DD>
<DD>Dao will now become like this.<BR>
<DD>class ProfileDao {
<DD> void insertProfile(Profile profile);
<DD> void Profile getProfile(String profileId);
<DD> void update(Profile p);
<DD>}<BR>
<DD> Client for this code will be like this.<BR>
<DD>
<DD> class ProfileClient {<BR>
<DD> void testAddAddress() {
<DD> Address address = new Address("112 Fifth Street", "NJ", "US", "08857"
);
<DD> Profile p = getProfile();
<DD> p.addAddress(address);
<DD> getProfileDao().update(profile);<BR>
<DD> }
<DD> } <BR>
<DD>This second approach looks cleaner, but the concern raised by my team mates
is that every time I need to add, update, delete a single address, I need to
load whole profile object in memory. This looks more like a "stateful"
implementation as opposed to "stateless" implementation of Dao Facade. If
Profile object is a huge one, then it can be a overkill to load the whole
object just to add/change one address. But I certainly dont like the facade
implementation. It does not allow me to do inserts/updates/deletes in batch. I
have to do operations one at a time. Secondly any object level validations or
business rules (Like Profile should have only one delivery address) are harder
to implement in facade approach. What is your opinion on this? Is this a
standard Domain Model vs Transaction Script issue?<BR></DD></DL></BLOCKQUOTE><
/DD></DL>
<DD>====================================================================
Companion Site: <A href="http://www.corej2eepatterns.com/" eudora="autourl"
>http://www.corej2eepatterns.com</A> J2EE BluePrints: <A href="http://java.sun
.com/blueprints/corej2eepatterns" eudora="autourl">http://java.sun.com
/blueprints/corej2eepatterns</A> List Archive: <A href="http://archives.java.sun
.com/archives/j2eepatterns-interest.html" eudora="autourl">http://archives.java
.sun.com/archives/j2eepatterns-interest.html</A> Unsubscribing: email "signoff
J2EEPATTERNS-INTEREST" to listserv@(protected) <BR><BR>
<DL></DL><BR><A href="http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r
/hs">Start your day with Yahoo! - make it your home page </A>===================
================================================= Companion Site: <A href="http:
//www.corej2eepatterns.com/" eudora="autourl">http://www.corej2eepatterns.com</A
> J2EE BluePrints: <A href="http://java.sun.com/blueprints/corej2eepatterns"
eudora="autourl">http://java.sun.com/blueprints/corej2eepatterns</A> List
Archive: <A href="http://archives.java.sun.com/archives/j2eepatterns-interest
.html" eudora="autourl">http://archives.java.sun.com/archives/j2eepatterns
-interest.html</A> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected) </DD></BLOCKQUOTE>=======================================
============================= 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)
</BLOCKQUOTE><p>__ ____ ____ ____ ____ ____ ____ ____ ____ ____ __<br>Do You
Yahoo!?<br>Tired of spam? Yahoo! Mail has the best spam protection around <br
>http://mail.yahoo.com
====================================================================
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)
|
|
