Handling children in an ObjectFactory

Handling children in an ObjectFactory

Old forum URL: forums.lhotka.net/forums/t/7082.aspx

Telison posted on Thursday, June 11, 2009

I have for some time trying to work out the correct patterns for handling children in the data access code in my object factory classes.

When implementing the data acces code in the business objects the methods to use are Child_Update, Child_Insert etc. Now, when using an ObjectFactory class instead am I right in my conclusion that these "child" prefixed methods are out of the picture? In other words in this scenario these details need to be implemented in the Objectfactory in a more manual fashion.

I just watched movie no six in the CSLALight movie series and from those instructions this seems to be the case.

RockfordLhotka replied on Friday, June 12, 2009

That is correct.

As I've discussed in other threads, the object factory model leaves all the work to the factory implementation intentionally so as to not reduce flexibility as people create their own data access layers using the model.

In other words, I presuppose that users of the object factory model will create a DAL based around the object factory model, not necessarily use it from scratch (as that requires a fair amount of work).

The DataPortal_XYZ model is intended for use when you want CSLA to do more work on your behalf.

Gort replied on Thursday, December 09, 2010

So, in this scenario, how would we go about actually saving child objects?  Would you suggest just calling the '.Update()' method on the DAL of a particular child object?  Is there a way to iterate through all child properties and then simply call .Save() on them, or something similar?

RockfordLhotka replied on Thursday, December 09, 2010

It totally depends on how you are choosing to implement your factory objects and DAL. There are so many different ways to do this...

For my part, if I'm using ObjectFactory, I tend to make my factory objects be the DAL, so they are what actually talk to the database. This is because ObjectFactory is already a level of indirection, and you can have many different sets of factory objects, one for each type of database or whatever.

But even if you make that assumption, you still have to pick a data access technology like raw ADO.NET, EF, L2S, NHibernate, etc. And that affects how you write your DAL code as well. I tend to use either raw ADO.NET or EF, with a preference for raw ADO.NET (connection/command/datareader/etc) since I think EF tends to complicate more than it simplifies.

Given those assumptions, I typically have a private method that is called by the public Update method - one private method for each child object type.

  1. The public Update method opens the connection, sets up any transaction, etc.
  2. The public Update method saves the root object's data
  3. The public Update method calls a private SaveChildX method, passing in ChildX
  4. The SaveChildX method saves the child data (in the case of ChildX being a collection, it loops through the DeletedList, then the active list, calling a SaveChildY method on each child)

Basically I look at a factory object as being responsible for persisting an entire object graph defined by the root object's type.

But I'm sure other people have different views and different approaches. And certainly the approach could be very different if you are using EF or NHibernate or other technologies, because you could (and should) create your own factory object base type (subclass ObjectFactory) to help streamline and simplify your code.

Copyright (c) Marimer LLC