generic child factory with CSLA 4.1.

generic child factory with CSLA 4.1.

Old forum URL:

menzel2911 posted on Monday, March 28, 2011

Hi folks,

does anybody know a way to implement an abstract child-object factory using DataPortal.FetchChild(of T) to get different types of child-objects depending on parent object state using Csla 4.1. and the encapsulated invocation model?

I have a root object which does have a managed "data" property (of data type object), which can be assigned to different child object types, depending on the situation (can be a child list, or a child). When retreiving the parent object, the decision will be made, of what type the data property will actually be and the Child-Factory is responsible to get the appropriate child object.

I tried to use an abstract function to return a child-object of T, but the child dataportal throws an exception, that abstract types cannot be fetched. Is it possible at all? I'm using the encapsulated invocation to retreive data, according to "Using Csla4 - Data Access" ebook.

Thanks for your help.

RockfordLhotka replied on Monday, March 28, 2011

The data portal isn't designed to do this in the encapsulated invoke model. In other words, you can't directly use FetchChild to do this.

There are some alternatives.

  1. You could use a factory implementation model - entirely abandon the DataPortal_XYZ and Child_XYZ methods in favor of object factories. This directly solves your problem, but is a completely different data access model.
  2. You could create a factory object for your child objects, with a factory method that invokes the appropriate FetchChild method for the child type. No matter how you approach this, somewhere in your app you'll have some method (or code implementing a pattern) to select the concrete type of each child. In this solution, just put that code into a child factory object, and have it invoke FetchChild for each concrete type.


menzel2911 replied on Monday, March 28, 2011

Thank you very much for the quick reply, that does help me very much.


Copyright (c) Marimer LLC