Kinergy posted on Sunday, August 06, 2006
Hi, let's suppose we want to create the following structure of BOs:
ParentRoot : BusinessBase<ParentRoot>
ChildCollection : BusinessListBase<ChildCollection, Child>
Child : BusinessBase<Child>
GrandchildCollection : BusinessListBase<GrandchildCollection, Grandchild>
Grandchild : BusinessBase<Grandchild>
(...could have more levels for great grandchildren...)
The template for a BusinessBaseList has a single method for populating the list with its child BOs (Child or Grandchild, etc.) that takes a SqlDataReader which is then passed on to the child. In the Project Tracker example, it is the Project BO method DataPortal_Fetch that calls the db stored procedure and retrieves two levels of data to populate the fields of the Project BO, as well as the ProjectResources object containing all the ProjectResource objects. If one were to create a third level with a grandchild it seems to me that this method of passing a SqlDataReader with enough data that could be somehow parsed into many GrandchildCollection objects doesn't work well. So, my question is, what is the recommended architecture for a 3+ level BO structure with collections? Should I create new stored procedures for each collection to call given that they can each filter the db table on their parent Id, or am I missing something?
Thanks in advance!
K
(I'm using CSLA 2.0.3)
Maccurt replied on Monday, August 07, 2006
Use a Dataset instead of a DataReader in this example, then use the relation object to create relations to all your data. I also created a new class called SafeDataRow that performs the same as the SafeDataReader. I am not suggesting you keep the Dataset around, just use it when you have those deep Parent-Child-Grandchild relationships.
