I have 2 classes inheriting from BusinessBase and one inherits from the other:
public
class OrgNodeProduct<T> : YoungLight.Business.BusinessBase<T>where T : OrgNodeProduct<T>
AND
public
class IpcNodeProduct : OrgNodeProduct<IpcNodeProduct>I now need a collection class that will handle holding both IpcNodeProduct and OrgNodeProduct, but I can't even get past defining the class!
public
class OrgNodeProducts : BusinessListBase<OrgNodeProducts, ???>Any help much appreciated, I'm a bit new to both CSLA and generics so apologies in advance for any idiocy on my part.
I went down this road myself and really started to run into some problems.
The answer might be to place an interface on OrgNodeProduct<T>, so that both IpcNodeProduct and OrgNodeProduct share a common interface.
Taking that further, OrgNodeProducts : BusinessListBase<OrgNodeProducts, IOrgNodeProduct>.
But then in the update of the collection it'll look to "Update()" and "Insert()" based on these children. The problem is that your interface will likely need to include some minimum set of properties you may want to expose as public, except that your Update() and Insert() for your child members you wouldn't want to expose as public.
Seeing that you can't have interface members with differing scopes, it's a little tricky. I looked at the idea of implementing an interface such as IOrgNodeProductInternal, which Update() and Insert() would be there for and thus then callable - you then have to, in the collection's update - cast the IOrgNodeProduct to IOrgNodeProductInternal, from which there you can update/insert using the internal interface.
Overall, the idea of using polymorphism with generics really gets a little difficult, and you may want to pursue the idea of having OrgNodeProduct not be generic and inherit from Core.BusinessBase rather than BusinessBase<T>, and you may find that things become a little simpler. (I haven't explicitly went down that route myself, I decided in favor of avoiding this whole area for a little while).
Whatever you do I'm definitely interested in what you end up with. Good luck.
I've certainly seen this article before myself (and is useful in understanding the beginning point) but what is the best solution to the update of the collection when Update() and Insert() must occur on the child objects?
The interface of the child collection is public (IEditableBusinessObject is public) and while Update() and Insert() could be added as public methods to the inherited interface, that's not ideal for encapsulation.
From: skagen00 [mailto:cslanet@lhotka.net]
Sent: Monday, July 31, 2006 11:50 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] BusinessListBase and InheritanceI've certainly seen this article before myself (and is useful in understanding the beginning point) but what is the best solution to the update of the collection when Update() and Insert() must occur on the child objects?
The interface of the child collection is public (IEditableBusinessObject is public) and while Update() and Insert() could be added as public methods to the inherited interface, that's not ideal for encapsulation.
Copyright (c) Marimer LLC