Fail to bind deep milti-level CSLA object graphic in CSLA .Net , and .Net 8 MVC app

[cedarlo3215]

Describe the bug
When binding a deep, multi‑level CSLA object graph in an HttpPost controller action using dependency injection, only the root (parent) business object is bound correctly. Properties on child and grandchild objects are not updated, even though they are posted from the view.

Version and Platform
CSLA .Net 9.1
.Net Core 8.0
MVC web application
Windows OS

Code that Fails
From debugging, it appears that CslaModelBinder only binds the first level of the object graph. Once a property of businessBase is a BusinessListBase, the model binder does not recursively bind updates to child or grandchild objects.

** Step to reproduce **

1. Define a CSLA object graph similar to the following:
   a) Business objects structure:
   - parent (BusinessBase)
   -- property1
   -- children1List (BusinessListBase)
   --- child[i]
   ---- childProperty1
   ---- grandChild1List (BusinessListBase)
   ----- grandChild[i]
   ------ grandChildProperty1
2. Create a view where:
   -- The model is Parent
   -- All parent properties are bound
   -- Child and grandchild lists are rendered in loops
   -- Child and grandchild properties are bound using standard MVC helpers (ex: parent .children1List [0].grandChild1List [0].grandChildProperty1)
3. In the UI, modify:
   -- Property1
   -- ChildProperty1
   -- GrandChildProperty1
4. Submit the form to an HttpPost action similar to:
   [httpPost]
   Edit(id,parent)

Except result: the value of grandchildProperty1, ChildProperty1, and Property1 should be updated
actually result: only the property1 is update correctly, however, all childProperty1and grandChildProperty1 are not updated

Additional context
I have the following questions:

1. Design expectation
   Is the current CSLA design intended to support only a single‑level root object (either BusinessBase or BusinessListBase) binding, and not mixed or deep object graphs with nested BusinessListBase objects binding?

2. UI / view model expectations

•  Is CSLA expecting MVC views to work only with relatively simple object graphs?
  

•  If users need to update children or grandchildren, is the intended pattern to:
            Navigate to a separate page for editing child/grandchild objects, rather than Updating parent, child, and grandchild objects in a single post?
  

3. TryUpdateModelAsync behavior
   I also tried the recommended pattern of fetching the parent first and then applying updates:
   [httpPost]
   Edit(id) {
   parent = FetchAsync (id)
   TryUpdateModelAsync (parent)
   }
   However, the result is the same: child and grandchild properties are still not updated.

[rockfordlhotka]

I'm trying to remember, but I am pretty sure the binder is working as designed. I don't recall ever implementing a whole-graph binding mechanism.

Not a bad feature idea - though I suspect it could be quite challenging to implement for a complex object graph with (for example):

• A parent with multiple types of child (how to detect the right child type)
• A parent with a list of polymorphic child types (again, how to detect the right child type for each item in the list)

It could be an interesting challenge to figure out solutions to those scenarios. Or, I suppose, ignore them and implement the simple path with some sort of disclaimer about no support for complex object graphs?