Modeling Persistence

Question

Hi,
I have a question regarding use of Domain Model pattern. 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?

Answer 1

Hi,
I have a question regarding use of Domain Model
pattern. 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
e could use it like following.
1. Clients will do all CRUD operations on Profile
e object itself.
2. All the classes will have isUpdated, isNew and
d isDeleted flag.
3. Dao will have just one update(Profile p)
) method.
4. Dao will check for updates and make queries
s 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. Stateful would only occur if the profile remained in session between requests. You can have a memory-intensive, stateless object (which I think is what you are concerned about).
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.I do not see how either of the designs above has a method siguature for batch operations. That having been said, this is no issue. Have an overloaded version of each method that also takes a Connection (or custom transaction) object. You can then execute each step "one at a time" but within a given transaction that can be committed as a logical unit of work.
If you are indeed concerned about memory requirements, consider implementing Lazy Load. Or have Hibernate do it for you.
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?Your DAO's seem to be your main issue and not the domain model. Transaction Script assumes there is a strong relationship between the relational and object models. O/R mapping technologies will tend to push you in this direction . Custom DAO's (via JDBC) can work in either instance. However, you should focus more on your model domain first, and then worry about its persistence afterwards (ideally). Your business logic will be implemented. How that object is persisted, while important from a performance consideration, should not overly affect your model domain.
- Saish