Design Issue with calculated fields

LStevnesUK posted on Monday, September 29, 2008

I have at the moment the following

Project (BO)
ProjectTaskList (Editable child list)
ProjectTask

ProjectResourceList (Editable child list)
ProjectResource

ProjectAssignments (Editable child list)
ProjectAssignment

My problem lies with trying to create the calculated fields on each object, for instance a projecttask needs an actual work property which is the sum of all assignment.work for this task, and a projectresource also has an actual work property which is the sum of all resource assignment.work. There are further calculated fields between project and tasks etc.

I'd like to try and implement it so the user can undo any changes so they can see any price changes on a what if basis but as there can be hundreds of tasks is this asking to much if I start to add projectassignments, resourceassignments, taskassignments etc for my calculated fields? Or I have I got it all wrong?

triplea replied on Monday, September 29, 2008

Your object tree explanation seems a bit vague to me... In any case below are some points that hopefully will place you on the right track.

If you are using CSLA 3.5 then there is a .Parent property on your child (or something like that). I have not used it yet but from what I gather it should allow you to navigate through your tree structure and access all the child lists. From there on calculating your fields should be easy.
If you are using a pre CSLA 3.5 version (or if the above doesn't work) then you could have the calculated fieds have their setters marked as internal and let the root object do the calculations (on create/fetch I would pressume). It might seem like its not the responsibility of the parent to contain the logic but then again the parent is the only object that has got easy access to all the child items.

Hope this helps

LStevnesUK replied on Monday, September 29, 2008

Thanks for the reply triplea: Sorry for vague explanation as its still all a bit vague at the moment!

I like the idea of putting everything into the root object: If for instance I had a child ProjectTaskList and a child ProjectAssignmentList is it then ok to calculate each ProjectTask.ActualWork by finding the task assignments in the ProjectAssignmentList? Or should each task have its own AssignmentList loaded from the the main ProjectAssignmentList?

triplea replied on Monday, September 29, 2008

Well it all depends on your use case. Are these assumptions correct?

A project has a number of tasks. Each task can have a number of Resources and Assignments. This would make your object tree look like this:

If that is the case then your calculations per Task should be easy as each task has got access to its child Resources and Assignments.

I think you are mixing up ProjectResourceList and ProjectAssignments (unless I did not get you right). The objects providing Resources and Assignments to a task (in the form of a picking list or whatever) should be read only lists (unless you need to specify these in the same screen in which case you would need a more complex structure).

LStevnesUK replied on Monday, September 29, 2008

thanks again that seems a much better idea, having the resources and assignments at the same level under the task (Just need to work out best way to load them all now!). They do need to see the resources on the same screen as the project as they can enter estimated values etc so would I also have an editable projectresourcelist under the project?

ajj3085 replied on Monday, September 29, 2008

If a resource is used in different tasks (i.e., use cases) you should probably have multiple resource classes, one for each specific use case. Only reuse a class if the behavior is to be identical in different use cases.