Hi-
the question is on an approach to design/implement Value Objects.
Example scenario:
A BANK in a REGION
So, Bank vo should ideally have - bankId, bankName, bankAdderss,..,regionId.
But the users of the Bank Vo is interested in RegionId as well as regionName. Especially, the presentation layer needs only regionName.
Now the question is: Is it a good design to pack region value object(say: regionId, regionName, regionSomeOtherDAta..) inside the bank value object instead of simply adding regionId?
According to me:
GAIN: you have all the data pertaining to region available when you have an instance of bank with you. especially, when you need region id,name together.
LOSE:if the region value object is faily big(heavy), the ultimate bank value object truns out to be bigger. And when we pass around a Collection of 100 bank VOs, it leads to a real memory bottleneck(and if the region is same for all the 100 banks, unnecessarily we are carrying 100 regions along with the banks).
What do you say?
pepper
-
Designing Value objects. (4 messages)
- Posted by: sgt pepper
- Posted on: November 19 2003 15:00 EST
Threaded Messages (4)
- Use of objects by leerutg leerutg on November 19 2003 16:03 EST
- Designing Value objects. by Badrish Agarwal on November 20 2003 01:16 EST
- Thanks by sgt pepper on November 20 2003 11:50 EST
- Just a random thought by sgt pepper on November 20 2003 12:10 EST
-
Use of objects[ Go to top ]
- Posted by: leerutg leerutg
- Posted on: November 19 2003 16:03 EST
- in response to sgt pepper
Ask yourself these questions:
1. how often is this bank VO accessed and how many concurrent users
2. How often is the region VO accessed (is it everytime bank VO is accessed?)
3. Is there a possibility that both bank and region VO may have additional attributes in future?
If bank VO is accessed frequently and a number of concurrent users are expected to access it and everytime region is needed then put it in one value object altogether.
If bank VO is not accessed so frequently and the region name may not be need all the time then separate them
Growth in attributes determines if your VO's are scalable. You may have to re-code parts of your implementation if you combine bank and region into one in future.
If these VO are a bunch of Strings you are ok on the memory side. -
Designing Value objects.[ Go to top ]
- Posted by: Badrish Agarwal
- Posted on: November 20 2003 01:16 EST
- in response to sgt pepper
One of the things you can do is lazy loading.
In bank object store region id and region object(null currently). if the region name is asked for then load the whole region object. -
Thanks[ Go to top ]
- Posted by: sgt pepper
- Posted on: November 20 2003 11:50 EST
- in response to Badrish Agarwal
Hey!! Thank you so much guys.
But the catch here is at earliest time of design one may not be able to identify the way his objects are going to be used. How did you guys create such VOs in your projects? -
Just a random thought[ Go to top ]
- Posted by: sgt pepper
- Posted on: November 20 2003 12:10 EST
- in response to Badrish Agarwal
If we have "lazy loading" logic with in the VO, I guess VO will no longer be a "Value Object". Its getter/setter s will start throwing unthinkable Exceptions.