Multiple Nested Collections in CSLA.NET 1.0

Gunner posted on Thursday, June 01, 2006

Hi, I've got a situation where I have many nested collections similar to the following:

Warehouse object contains collection of Shelf objects

Shelf object contains collection of Box objects

Box object contains collections of Ball objects and Doll objects

With just one collection as the property of an object, I know the Fetch can load both the main object and the collection data in with the same procedure, but I'm not sure how to write the code & sql to do multiple layers. Can anyone help?

hurcane replied on Thursday, June 01, 2006

Do you have a use case where you are editing the warehouse, shelves, boxes, balls and dolls all at the same time? Is there a single maintenance form that manages all of these objects simultaneously?

Usually when you design a complex hierarchy like this, it is due to having a broad data focus instead of a specific behavior focus. I'm willing to bet that your maintenance forms aren't dealing with more than a couple objects at a time. For maintenance, design your objects in the context of the business case that supports the specific maintenance form.

You should also consider Navigational context. The shelf maintenance form may need to provide access to the warehouse maintenance form. ProjectTracker has this kind of navigational context between a Project and a Resource. You could have this navigational context between Warehouse <-> Shelf, Shelf <-> Box, etc.

RockfordLhotka replied on Thursday, June 01, 2006

If you really do need to load grandchild objects (which does happen fairly often), you can't use the technique shown in the book. It isn't realistic to use a single stored procedure call to load all the data - at least not unless you are willing to do a lot of work to reconcile which data goes with which child.

This topic was discussed quite often on the old forum - so you might try www.searchcsla.com to find an answer. Many people, from what I read, chose to use a DataSet to load the data (because it does the complex reconciliation) and then load your objects' fields from the DataSet. That makes for pretty simple code in your data access methods and provides a reasonably elegant solution overall.

amselem replied on Thursday, June 01, 2006

Most people here use the DataSet approach with complex hierachies but I opted to stay with the datareader instead. If anyone is interested, I described this approach in the old forum: http://www.searchcsla.com/Details.aspx?msn_id=24427
As Rocky said some work has to be done to reconcile the data with the BO hierarchy; my approach does all this work in the stored procedure instead of the BO's, so all of them can load the data through a datareader.

esteban404 replied on Thursday, June 01, 2006

I am interested to know the purpose of the temp tables. I probably just haven't experienced the need, but I'd like to understand it. I read the linked thread, but didn't quite get it. Seems like the tables were used to hold hierachical data in limbo so it could be order-read into the BOs. I use separate select statements for child, grandchild data these days.

Oh, yea, and type slowly please. :-] I'll see if I can pursue the dataset approach more, too. My colleague favors that.