ChildDataPortal objectfactory

The object factory model TOTALLY DELEGATES ALL RESPONSIBILITY TO THE FACTORY OBJECT.

In other words, you can load your child objects however you’d like – it isn’t CSLA’s responsibility any longer.

The ultimate goal of ObjectFactory is to allow an ORM (specifically some future version of ADO.NET EF) to totally create and populate your object graph from the database. In that case the ORM would create the child objects and load them with data. How will that work? That depends on what Microsoft ultimately does with EF – and the answer is unknown today.

Ignoring EF, the short answer is that you need to devise your own interface or technique for how your factory object will interact with your business objects. I intentionally didn’t solve that problem, because there are numerous possible solutions – each with pros and cons – and until I know where EF is going I can’t effectively choose between them.

In Chapter 18 I discuss a number of data access solutions and techniques – and that’s not even an exhaustive list, just the highlights. If I picked any one of them as the exclusive way to do persistence I’d piss off more people than I’d make happy.

I certainly don’t see ObjectFactory as the ultimate replacement for the normal data portal behavior. The normal data portal behavior is far simpler to code, and is probably preferable for most scenarios.

However, like I said in another thread, as time goes on it may be that some specific pattern emerges that is clearly the “right way” to use the object factory, and if that happens I may make CSLA directly support that pattern – as long as it doesn’t interfere with the primary goal of supporting some future version of EF.

Rocky