Contract / Project / Line-Item hierarchy design considerations
- by Ryan
We currently have an application that allows users to create a Contract. A contract can have 1 or more Project. A project can have 0 or more sub-projects (which can have their own sub-projects, and so on) as well as 1 or more Line. Lines can have any number of sub-lines (which can have their own sub-lines, and so on).
Currently, our design contains circular references, and I'd like to get away from that. Currently, it looks a bit like this:
public class Contract
{
public List<Project> Projects { get; set; }
}
public class Project
{
public Contract OwningContract { get; set; }
public Project ParentProject { get; set; }
public List<Project> SubProjects { get; set; }
public List<Line> Lines { get; set; }
}
public class Line
{
public Project OwningProject { get; set; }
public List ParentLine { get; set; }
public List<Line> SubLines { get; set; }
}
We're using the M-V-VM "pattern" and use these Models (and their associated view models) to populate a large "edit" screen where users can modify their contracts and the properties on all of the objects. Where things start to get confusing for me is when we add, for example, a Cost property to the Line. The issue is reflecting at the highest level (the contract) changes made to the lowest level.
Looking for some thoughts as to how to change this design to remove the circular references. One thought I had was that the contract would have a Dictionary<Guid, Project> which would contain ALL projects (regardless of their level in hierarchy). The Project would then have a Guid property called "Parent" which could be used to search the contract's dictionary for the parent object. THe same logic could be applied at the Line level.
Thanks! Any help is appreciated.
