Now that I have moved away from creating my Root business objects (e.g.: Employee.HourlyEmployee and Employee.ExemptEmployee) using SuperType / SubType inheritance I'm now confronted with figuring out the best practice for coding and maintaining the child collections that are contained within the multiple de-normalized EditableRoot BO's.
Both Hourly and Exempt employees contain a collection of PerformanceReviews and TrainingCredits ... and I am wondering about the alternatives that I need to consider when coding the Insert() and Update() functions in those EditableChild BO's and the Update() function in the EditabaleChildList().
Will I have to create 2 separate sets of EditableChild and EditableChild list classes for each of the (very similar) collections in the Root ?
ie: HourlyEmployee.PerformanceReview and ExemptEmployee.PerformanceReview
and
HourlyEmployee.PerformanceReviewList and ExemptEmployee.PerformanceReviewList
I could get around the need to name the classes uniquely by putting them in separate namespaces and packages/directories
But I still need to resolve the issue of using strongly typed parameters to the Insert() and Update() methods of the EditableChildren and the Update() method of the EditableChild list.
Is this a case where I implement an IEmployee interface in Exempt and Hourly and type the parameters to the Insert and Update methods in the contained collections and editable children using IEmployee ???
Will implementing IEmployee allow me to pass that interface instead of an object Type to the methods in the editable child and editbable child lists ????
Steve
Steve,
Just remove the question marks and you provided your own answer.
e.g.
This is a case where you should implement an IEmployee interface in Exempt and Hourly and type the parameters to the Insert and Update methods in the contained collections and editable children using IEmployee.
Implementing IEmployee will allow you to pass that interface instead of an object Type to the methods in the editable child and editbable child lists.
Note: I decided a while back to only bother passing the Parent object to the child in the Insert method. And then, only if there is a database Identity field involved. In your case, if an employee is added to the DB and EmpId is an Identity which is generated upon Insert, then the BO will get a new updated value which must be passed to its children so they can be properly inserted. I haven't had much use for passing the Parent in other cases, so I don;t bother anymore.
Due to this I created an Interface named IParent (I think Rocky just created one with that name recently too) with a single Property of Key as Integer. This way I can always pass the BO that implements this interface as the parameter to the child objects and get the new Key value from it.
Joe
ok ... I'll go with that pattern ... thanks, Joe ...
I *am curious* however ... is there much overhead passing a reference to the entire parent object .... seems like there is not much need for the child to know about the parent except for it's ID ...
Any elaboration on this IParent functionality related to this ????
thx,
Steve
tsaltd:
is there much overhead passing a reference to the entire parent object .... seems like there is not much need for the child to know about the parent except for it's ID ...
1. Passing a reference to an object is very lightweight as it is only a memory pointer to the real object.
You can't get much lighter weight than that.
2. I concluded the same thing about the ID so that is exactly why I built my interface with a single property named Key As Integer. So if I have an InvoiceKey or ReceiptKey or PurchaseOrderKey I can just use the Interface to pass the object to its children where they can extract the key. Again, I only found this necessart because they are Identity fields in SQL Server and the parent BO does not have the correct value until the Insert occurs.
Joe
Copyright (c) Marimer LLC