modelling a network of objects

nampord posted on Monday, January 26, 2009

I need to model a network of tasks for a project management solution, where every tasks can have an arbitrary number of successor tasks ( which in turn have successors and so on ...). Since a task can have more than one predecessor it is a network of task.

There is a use case to visualize the entrie network of tasks. And some busienss algorithm need to be able to quickly traverse the network.

What is the best way to model this with the collections in CSLA?

Ideally I woudl like to hold a reference to all the successors tasks with each task in order to have access to all the successor's properties. But making the successor tasks a child collection of task will not work since a task can have more than one parent.

I could just store successor id's and construct the references by hand once all tasks are loaded. But I wonder if there is a better way ... ?

Thanks for you input

RockfordLhotka replied on Monday, January 26, 2009

This is a variation on a many-to-many relationship, or perhaps one-to-many.

Either way, the secret is to remember that objects model behavior, not data. Object relationships model behavioral relationships, not data relationships. Finally, many objects reflect the relationship as much as they do the concept/behavior.

In other words, a task has successor tasks. But a Task is a top-level root concept. So you have this:

Task
SuccessorTaskList
SuccessorTask

And SuccessorTask represents the relationship between this Task and other Task objects. So SuccessorTask will have a navigable using relationship to Task, but it is not a Task itself, because it represents the relationship.

You can see this in the ProjectTracker app, where a Project has a list of ProjectResource objects, not a list of Resource objects. This is because a project has a relationship with some resources, but doesn't actually contain the resources themselves.

If you stop and think about this in real-world terms this makes sense. Does your doctor own or control you? When you purchase a product at a store, does the sales order own or control you? No. The doctor has a relationship with you. So does the sales order.

Similarly, a Task doesn't own or control other Task objects. It has a relationship with them. And your object model needs to reflect that relationship.

nampord replied on Tuesday, January 27, 2009

Thanks for the quick reply, Rocky

This makes things much clearer in the design and in fact the link between tasks has some properties itself so the SuccessorTask is the right place to store these link properties.

However my case is somewhat different from the case

Project
ProjectResources
ProjectResource

as in my case the navigable using relationship is between the objects themselves (i.e. between tasks).

The question is how efficient can one support the navigation between the linked objects:

In your Project example ProjectResource implements a GetResource method , which fetches the Resource object with a given Id.

In my case I will have all tasks already fetched ( they are children of a Project root) and certainly dont want to go back to the database each time I navigate the network of tasks ( which will be a very frequent operation)

For efficiency if would be great if the SuccessorTask object could hold a reference to the linked task itself, in order to navigate without the need to involve a lookup table, index or even a fetch from the database. This reference would need to be nonserializable and filled once all tasks are fetched.

I wonder if I am heading into a dead end with such an approach (e.g. when considering undo of creating or deleting the links between tasks)?

Thanks

Frank

RockfordLhotka replied on Tuesday, January 27, 2009

I think it depends on whether you want this graph to be composed of directly editable objects or not.

If not, then you can use ReadOnlyBase and ReadOnlyListBase and you can do exactly what you want. That is a supported scenario.

If the objects need to be editable, then it can get quite complex. The primary challenge you’ll face is that the current CSLA infrastructure only supports parent-child relationships between objects. If you have a network of peers, then you have a network of root objects.

This means you’ll end up fighting with some of the existing infrastructure, in particular BusinessListBase, and to a lesser degree the data portal. You may need to create your own collection type, like BLB but different, that supports root objects. Maybe you can use EditableRootListBase, but I’m skeptical, because this is outside the design parameters for that type.

If you want these objects to be editable, I would strongly recommend a parallel model, where you have the graph itself as read-only objects (ROB, ROLB), and when the user selects a node, you create a root BB object so they can manipulate that one object. When they save their changes, you’d pull the data from the in-memory BB object to update the ROB in the graph.

Rocky