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@java.sun.com