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