CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Implementing Objects as Root or Child within hierarchical structures?

rated by 0 users
Answered (Not Verified) This post has 0 verified answers | 2 Replies | 2 Followers

Top 500 Contributor
23 Posts
Alexander Becker Huh? [:^)] posted on Thu, Oct 13 2011 3:25 AM

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:

  • class Contact { IEnumerable<ContactRelation> RelatedContacts; }
  • class ContactRelation { string RelationType; Contact RelatedContact; }

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:

  • class Item { IEnumerable<Item> Children; Item Parent; }

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. 

All Replies

Top 75 Contributor
112 Posts

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).

 

Top 10 Contributor
3,922 Posts
Answered (Not Verified) Andy replied on Sun, Oct 16 2011 10:41 AM
Suggested by Andy

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.

Page 1 of 1 (3 items) | RSS

Copyright (c) 2006-2010 Marimer LLC. All rights reserved.
Email admin@lhotka.net for support.
Powered by Community Server (Non-Commercial Edition), by Telligent Systems