Hello,
after reading the CSLA4 books I am not sure how to implement the following scenario:
given the following classes to build up a simple contact management:
Any contact can be referenced to any other contact or to itself.
The count of references between any two contacts is not limited.
So, how to implement the Contact BO? Inherit from BusinessRoot or from BusinessChild?
The same problem I have with a self referencing tree system:
What base type has the Item BO to be of?
Thinking about a filesystem, I could argue the Partition is the BusinessRoot and the Folder would be a BusinessChild.
But when you look at any Subfolder on its own, is this one a Root with Childs?
I am puzzled about this concern.
Any help?
thank you,
Alexander.
Hi,
I would model both as root objects (Contact and ContactRelation), unless you can draw a a clear picture of your object graph.
I think, the question is what you want to load immediately and what you need for update? With child objects you tend to load them immediatly. But with your statement "Any contact can be referenced to any other contact or to itself" you will end in cycles and endless-loading-loops.
The second sample of a strict hierarchical tree system can work with child items, if you like to load and update the tree only through your very root node object.
Using trees (and display them in UI) I found this a good approach: The tree is implemeted with read-only objects and lists limited to a minimum properties needed in a tree view, such that it can be loaded fast. If you selected a node in the tree you load an probably editable object with more/all properties.
(btw you always inherit from BusinessBase but mark it as a child).
I'd implement a Contract BO for editing your contract. Then a ContractRelationshipList as a root ReadOnlyListBase which contains ContractRelationshipInfo objects. You can then have command objects for adding or removing a relationship, or if there's data that exists only as part of the relationship ,have a ContactRelationship root BO. You can then use that type for adding, editing or deleting a relationship.
Copyright (c) Marimer LLC