DAO Design 2005-08-20 - By unmesh joshi
Back
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?
__ ____ ____ ____ ____ ____ ____ ____ ____ ____ __
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>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER
-LEFT: #1010ff 2px solid">
<P>Hi,</P>
<P>I have a question regarding design of DAO. In our project we are creating
customer profiles. We have modeled profile like this</P>
<P>class Profile {<BR> Name name;<BR> List<Address>
addressList;<BR> List <Phone> phoneList; <BR> ....<BR>}</P>
<P>We have CRUD operations for Profile, Addresses, and Phones.<BR>For crud
operations, we have DAO facade like this</P>
<P> class ProfileDao {<BR> void insertProfile(Profile
profile);<BR> void Profile getProfile(String profileId);<BR>
void addAddress(String profileId, Address a); <BR> void
addPhone(String profileId, Phone p); <BR> void updateAddress
(String addressId, Address a);<BR> void updatePhone(String phoneId,
Phone p);<BR> void deleteAddress(String addressId);<BR>
void deletePhone(String phoneId); <BR> ..........<BR>
<BR> }</P>
<P> <BR> Client for this code will be like this.<BR> <BR> 
;class ProfileClient {<BR> void testAddAddress() {<BR> Address
address = new Address("112 Fifth Street", "NJ", "US", "08857");</P>
<P> String profileId = getProfileIdentifier();</P>
<P> getProfileDao().update(profileId, address);<BR> <BR>
} <BR> } </P>
<P> Instead of using Facade like this, I thought we could use it like
following.</P>
<P> 1. Clients will do all CRUD operations on Profile object itself.<BR>
2. All the classes will have isUpdated, isNew and isDeleted flag.<BR> 
;3. Dao will have just one update(Profile p) method.<BR> 4. Dao will
check for updates and make queries accordingly<BR> <BR>Dao will now become
like this.</P>
<P>class ProfileDao {<BR> void insertProfile(Profile profile)
;<BR> void Profile getProfile(String profileId);<BR>
void update(Profile p);<BR>}</P>
<P> Client for this code will be like this.<BR> <BR> class
ProfileClient {</P>
<P> void testAddAddress() {<BR> Address address = new Address(
"112 Fifth Street", "NJ", "US", "08857");<BR> Profile p = getProfile();<BR>
p.addAddress(address);</P>
<P> getProfileDao().update(profile);<BR> <BR> }
<BR> } </P>
<P>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?</P>
<P> </P></BLOCKQUOTE></DIV><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)
|
|
