Wednesday, March 09, 2005
Strategy for binding Interface implementations from Spring with Hibernate object
This is a very esoteric blog, it's more of a mental memory dump for myself incase I ever need to recall this "design pattern"
1. Phone interface
2. Vendor's Phone interface implementation
3. PhoneData hibernate object w/access to perisent data for all phones
4. Line interface
5. Vendor's Line interface implementation
6. LineData hibernate object w/access to perisent data for all lines
1. Let interface be service driven, easy to implement
2. Let database store simple properties and not burden implementation with menial getter and setters and allow interface and persistent objects to evolve independently of each other
Phones have 1-to-many relationship with lines and hibernate is great at dealing w/that however hiding data objects at least when it comes to adding and deleting lines becomes very difficult.
Dao needs to wrap each read/write of data objects to return interface implentations. Therefore fancy queries that return complex object graphs are not really useful.
Given that all queries need to be "wrapped" advantage of having hibernate manage the collection is minimal. Therefore, if phone interface manages a "simple" collection, Dao can read/write collection in only a few isolated places. I say "simple" because one trick is being able to recall what lines need to be deleted. A simple Collection subclass handled this trick.