Editable Child Object List ... With Read-Only Children... Or Maybe I'm Confused.

[polanddm]

Hello again CSLA!

In a previous query in CSLA discussions, I asked about experiences of the community in modeling Tree data structures to try to begin a rather large project with the best information and "lessons learned" I could...

A second aspect of this project is a fairly systemic requirement to allow "mapping" elements of disparate parts of the overall object model to other elements. For example, suppose I have

root.EditableRedList<RedThing>
root.EditableBlueList<BlueThing>

The requirement is can be illustrated with something like this:

root.EditableBlueList[0].MappedRedThings<RedThing>

The purpose of the "MappedRedThings" property is to allow the "mapping" (add or remove, not modification) of "RedThings" to an individual "BlueThing".

So, one could say that the "MappedRedThings" is an editable list, but with read-only Children.

I am having a little trouble relating this situation to the discussed Class and Property "stereotypes" in CSLA documentation.

This also seems like a List<> version of the intergraph property stereotype, but I do not want to assume this is a good approach.

I am very curious of any community experiences with similar situations.

Your feedback would be greatly appreciated.

Thank you,

Doug
[email protected]

[rockfordlhotka]

What are the expected sizes of these lists? 10 items or 10k items (or more)? There are some simple solutions for object graphs of a few hundred items that may not perform of an object graph of 10s or 100s of thousands of items.

Regardless, one thing to consider is the use of command objects to update the underlying data store to match alterations done to the object graph. So rather than having the user manipulate the object graph and then saving the entire thing, it is sometimes possible to save each individual manipulation of the graph immediately, thus keeping the in-memory graph and the underlying data store in sync.

[polanddm]

@rockfordlhotka Thank you for the reply and recommendation regarding the use of command objects. The mapping lists will vary in size, but based on examining data in current datasets, in most cases, they will be on the order of 10-20 "mappings" (the nature of the data would never demand 100s or 1000s of mappings).

The mappings themselves (intergraph object references added/removed, but source object not edited) are definitely of a nature that undo should be supported, which was the genesis of the odd title to this discussion.

On a slightly related note, I have a few scenarios in the requirements where a Child Object (not a list, but rather following the "Using" stereotype) need to be changed. By changed, I mean swapped with another Child Object, not a modification of the Child object. From a UX perspective, I envision a drop-down list allowing the selection from a list of Child Objects of like type. I suppose on consideration this is a singleton version of a mapping, so perhaps the approach should be similar. But, again, the need for undo capability is definitely a requirement. Sorry for adding this in and not creating a separate discusion thread, if desired, I can do so.

Thank you again, it is kind of cool to get a response for the authority of CSLA!

Doug