Fetch-root-plus-children BUT create-if-not-found best practice question !!??

lewischris posted on Monday, August 07, 2006

Hi,

I am VERY  new to CSLA (about 3 days), and am currently using v1.5 as we are still .NET 1.1. Please forgive any terminology issues!

I have an object hierarchy as follows:

CardHolder (root)

   -> Card (child)

   -> DrivingLicence (child)

   -> DriverCardHolder (child - controls assignment of a driver record to a CardHolder record)

         -> Driver (switchable grandchild - can be root)

   -> CardHolderDepots (child list)

      -> CardHolderDepot (child - controls assignment of a depot record to a CardHolder record)

         -> Depot (switchable grandchild - can be root)

I should emphasise that I am working with an existing database with legacy tables and data, but with new tables being added for new objects.

When fetching a CardHolder instance from the database, I first need to check on its existence using a key, and apply these rules:

If it does not exist, then create it and it's children as necessary. This I think is straightforward enough.

ELSE

If an instance of CardHolder can be found, then fetch it. My question is: At this stage I also need to populate the object hierarchy BUT (and this is the where I need some design-style advice) at any level in the hierarchy the child/grandchild objects are not guaranteed to exist or new instances may need to be created to reflect changes - so they must be created as needed - how should this be coded? Does this kind of logic go inside business objects? I haven't seen any examples of "Fetch but create (plus children) if it's not there" type methods?

I hope this makes sense!

Thanks for any help.

Chris

RockfordLhotka replied on Monday, August 07, 2006

I recommend looking at this from the use case viewpoint rather than the data viewpoint. You already have a switchable object, which should be very, very rare - a move of last resort actually. This indicates (in most cases) a data-centric design rather than a behavior-driven design.

I assume Depot is a root because you can edit Depot objects as a seperate use case. That's fine - but there should be a set of objects for that use case - different from the set of objects that allow you to associate a CardHolder with a Depot. In other words, CardHolder should have a collection of AssociatedDepot objects rather than Depot objects. (it is unlikely that CardHolder actually has ownership over a Depot).

In terms of your original question - yes, the child objects should be added through their parent - typically actually being only added to the database when the root object is saved.

lewischris replied on Tuesday, August 08, 2006

Thanks for the insight - it's helped me get my thinking straight.

You're quite right - I'm migrating code from a very data-centric design, and need to start thinking in terms of object behaviour on a use-case context basis.

Chris