Root object with six/seven child objects.

[Chicagoan2016]

We have a root object that has six/seven child objects (long story about the UI).
Right now each object has a different stored proc. We are thinking of coding a 'master' stored proc that will get all the data (for root and children) in one call.
Is it worth the effort? one of our developers thinks so : ).
Before we start changing the code I would like to hear opinions from fellow Csla developers.
Kind Regards

[ossendorf-at-hoelscher]

We have similar abominations :). We started to switch to load the whole "object graph" from the database where possible in one go. Especially with child-lists to increase performance. Each database call costs you "time" which is even within our company network noticable.

[Chicagoan2016]

@ossendorf-at-hoelscher Thank you Sir. Do you recommend we go to the whole object graph loading in one call?

[ossendorf-at-hoelscher]

I recommend: Measure the current loading time. Prototype the "load whole graph" and measure again. Whichever is faster can be used :)

[Chicagoan2016]

@ossendorf-at-hoelscher which was one faster in your case? I will take your word for it : )

[ossendorf-at-hoelscher]

As already stated. One tailored DB call is faster than multiple. But it really depends on your data structure. For us one time loading is in most cases faster.

[Chicagoan2016]

Thank you Sir.

[saulyt]

Another possible option is to do the data calls and loading for the parent and children asynchronously. This way they can be loaded simultaneously. I've done this a few times with large object graphs and it's been very fast. In the beginning of the Fetch I create all the fetch tasks for the parent and children and then use await Task.WhenAll(....) and set the children with the results of the tasks.

[saulyt]

Sure. The below code is from a Complaint object. It has a child list of FileLinks and a child list of Correspondence. The complaint DAL is injected into the fetch which is used to retrieve the parent object. The DataPortals for both the FileLinkList and CorrespondenceList injected as well to handle retrieving the children. (Automapper is being used to map from the DAL to the business object so that is injected as well.)

[Fetch]
private async Task FetchAsync([Inject] IComplaintRepository dal, [Inject] IMapper mapper,
	[Inject] IDataPortal<FileLinkList> fileLinkPortal, [Inject] IDataPortal<CorrespondenceList> correspondencePortal,
	int complaintID)
{
	using (BypassPropertyChecks) 
	{
		var entityFetchTask = dal.FetchAsync(complaintID);
		var attachmentsFetchTask = fileLinkPortal.FetchAsync(complaintID, this.LinkTypeID);
		var correspondenceFetchTask = correspondencePortal.FetchAsync(complaintID, this.LinkTypeID);
		await Task.WhenAll(entityFetchTask, attachmentsFetchTask, correspondenceFetchTask);
		mapper.Map(entityFetchTask.Result, this);
		Attachments = attachmentsFetchTask.Result;
		Correspondences = correspondenceFetchTask.Result;
	}
}

[Chicagoan2016]

@saulyt Thank you so much. I am going to try this first. It looks I don't have to change the stored procs.

[ossendorf-at-hoelscher]

Some notes: Yeah parallelization is also a great way to improve speed.
If you are using EF Core this (sadly) won't work executed on the server because the DbContext isn't thread safe.

[Chicagoan2016]

@ossendorf-at-hoelscher I am using 'native' ADO.NET and stored procs.

[swegele]

We have similar abominations :).

Ha - us too...and 3 levels (Grand-Parent-Child). Agree with @saulyt recommendation. It works nicely to do WaitAll or WhenAll async. Worked great because our DAL could handle it threadsafe.

We also have the child list properties set to lazy load. This let's you pick for the scenario - aggressively load them all up front or let the load happen as the user lights up different parts of the UI. So far this performs pretty nicely for child lists that have counts in the high hundreds. If you get larger than that you will need to refactor to fetch pages at a time or do your loading with ReadOnly objects for display until user picks something to edit.