Design question conserning children objects

Design question conserning children objects

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


antoan posted on Wednesday, September 20, 2006

I am working on a configuration app as part of a voip soultion which has a structure similar to that of Rocky's ProjectTracker.

The major objects in my model are:

Customer [Exidable Root] - Represents Customer Id (Guid), Name

DDI [Editable Child] (direct dial in number)

Extension[Editable Child] - Id, integer value, has a name.

Essentually a Customer can have a number of DDI's which map to a number of Extension objects of that customer, similar to the many to many mapping found between Project and Resource objects in ProjectTracker.

I began with a design which involved aggregation or has - a implementation between parent( Customer) and child(DDI, Extension) objects. In odrer to implement the many to many mapping I used a list of grand child objects (relative to the root Customer) analogous to ResourceAssignment and ProjectResource. Eventually decided to simplify things to avoid a parent-child-grandchild arrangement.

Currently Extension's and DDI's are modelled as root objects and are associated with a Customer via the Customer's ID, ie the DDI and Extension remain as logical child elements but are implemented as root types.

The problem I have with this is how to keep track of loaded and newly created DDI and Extension objects and manage their association with Customer object without implementing too much business logic in the UI Logic/Controller layer?

Has anyone come across a similar set up? Would appreciate your comments.

A

RockfordLhotka replied on Thursday, September 28, 2006

You might consider creating Customer as a top-level object that contains these other root objects. Somewhat like the EditableRootListBase in version 2.1 - where the top-level object knows how to retrieve the other objects, but doesn't manage their lifetimes beyond that point.

If you make your DDI and Extension objects such that they have no public factory, then the only way the UI could create instance of them is through a top-level Customer - which would help you enforce the relationship.

Copyright (c) Marimer LLC