Modeling Tree Structures with CSLA BusinessListBase<T,C> & Intergraph Properties

[polanddm]

Greetings CSLA!

I am somewhat new to CSLA and I am in the process of evaluating a CSLA-based implementation of an existing object model that makes significant use of Tree structures (single Root node).

The nodes of a Tree can be readily stored and manipulated with the BusinessListBase<T,C> generic.

The ParentNode of a Node, I assume would be modeled as a property following the "Inter-graph" stereotype.

From Nodes with Parent Nodes, additional read-only properties can be algorithmically determined (IsLeaf, Root, etc. - also, presumably, "Inter-graph" stereotype properties of a Node ) and, I believe, binding to "Tree-type" UI controls will be possible (at least based on Windows Form's experience).

A requirement of the application in question is the ability to "re-order" nodes in a tree. An editable "Index" property on Nodes should suffice here.

I am curious as to any experiences the community has had in representing Tree structures using CSLA infrastructure and, notably, any "gotchas" in things like serialization, undo, etc.

Any sage advice would be welcome as the object model in question is very large and I would like to have a clear understanding of best approaches before starting to flesh out the code base.

Thank you for considering this query!

Doug
[email protected]

[hurcane]

We have a "bill of materials" that is represented by a theoretically unlimited set of nested objects. In our case, we have a common interface to model the structure because the nodes in the BOM can have difference concrete instances (e.g. stock item, labor, external service, accounting fee, etc.).

We allow re-ordering nodes, but only within a single structure. That was a deliberate design decision on our part because it is not common in our environment to move child nodes between "parent" nodes. Drag and drop events make calls on the structure interface, which defines a move method to take care of internal updates (i.e. the index values). There is nothing technically that would prevent moving between parent nodes, but you'd have to figure out responsibilities between the multiple nodes when changing the parent.

One big caution I would make is to not load an entire tree of editable business objects. Editable business objects are heavyweight to construct and run business rules, even with async methods. We did this, and the user interface became unusable when some users were trying to edit a BOM with nearly 100k components. We had to switch to a model that started out with "info" objects, but the UI will swap in a fully editable object when needed. This was a huge task to redesign. Data updates are treated as independent actions, rather than saving as a single entity. It's much more complex to coordinate, but the performance benefits were immense.

[polanddm]

@hurcane Thank you for that response; that is excellent information and, IMO, definitely falls into the "sage advice" category! Your description of how to avoid "too many editable business objects at one time" is sound advice and I very much appreciate it.

[rockfordlhotka]

When you say "tree", do you mean binary tree, red-black tree, or some other specific algorithm?

Storing elements of a tree in an array or list, with the tree itself implemented as a data structure using the index location of each node in the array is not uncommon, but you can also implement a tree directly without such an array - it kind of depends on what you are trying to accomplish.

@hurcane is absolutely right though, you don't want to use CSLA objects to basically re-create entire tables from the database in memory, as that way lies a lot of difficult issues.

One thought, again depending on your needs, would be to use a DynamicListBase (DLB) to load (basically) an array of editable root objects, and then have your tree structure use the index values of those items.

The DLB type allows you to fetch a bunch of editable root objects, and then save them individually rather than as a big block. It is particularly valuable for binding to a data grid, where the user may only edit a few rows. It might be something that can be adapted to this scenario if the common thing is to rearrange the tree, and editing of individual nodes is sporadic.

[polanddm]

@rockfordlhotka To be more precise, these are general n-trees - with the constraint of a single root node. Good examples from similar domains would be the Task hierarchy in MS Project, a Work Breakdown Structure (WBS), or even a document outline from MS Word. Of course, a file-system directory/file is a dead-ringer structurally. In this particular solution, these n-trees will typically have less than 10,000 total nodes and, usually, any given parent node will have 5-50 "child" nodes.

Thank you for the insight into using DLB. I had honestly not thought of that, but it fits the scenario rather well.

Your recommendations, along with @hurcane are spot-on. While node ordering and node "re-parenting" are real use cases, they are lower priority. In fact, from a review of user feedback and analyst recommendations, it appears to be a more common desire to update these trees through import of, for example, MS Excel worksheets (following a template). From a neophyte's perspective, this appears to be a good scenario to employ Command/UoW sequences.