Blazor advice for complex object graphs

[michaelcsikos]

In most Blazor examples the models are fairly trivial. With WinForms UI we have had no problems with very large editable models containing lists of children + grandchildren, and even deeper object graphs.

With Blazor is there a practical limit to how deeply our object graphs should be, both from a performance and/or difficulty in implementing the UI? Should we be breaking up the graph into independently saveable objects? Thanks in advance.

[rockfordlhotka]

I don't know the answer to this question. I think Blazor is still new enough that we lack data on what works and doesn't work in practice.

[TheCakeMonster]

As I read this question, the thought that came to my mind was that, to some extent, the answer to this is related to how you want the user interface to work - what you are using the objects for.

In general we tend to go for a flatter design in the UI for web apps. We can't stop users from closing the browser at any point, so the danger of very complex, multi-level graph edits is that the user gives up and closes the browser tab. Your graph is generally only going to be valid, and capable of being saved, when the user finishes an edit on the root. If you have them walk through a multi-level object graph, editing children and grandchildren, and they lose interest or run out of time part way through, there is a danger that they lose all of their work.

Splitting things up into more manageable chunks, with smaller object graphs, gives them more opportunity to save their changes along the way.

But that's why I say it's related to the UI experience as much as anything else.

[swegele]

I agree with @TheCakeMonster and I can add some thoughts/experience. We are upgrading to Blazor SS so I'm watching closely for new data related to your exact question.

Our existing WebForms UI uses editable objects with a combination of lazy loading child lists and grand child level lists too. It's super convenient!

• Generally we fetch the ROOT editable
• Pass a clone of the ROOT (and the id of relevant child being edited) into child popup edit pages. This enables cancel back to original.
• The children and grandchildren lazy load themselves as the user navigates through the various sub screens.
• We have one main tab that gives "Broken Rules" feedback on initial load. Then as the user behavior loads additional child objects and thus additional potential broken rules, we have to alert the user when that happens so they can pop back into the broken rules tab to see what's up.
• Upon close of child page we check if CLONE ROOT was saved and if yes then we do the necessary replace/refresh of ORIGINAL ROOT on base/main page

But I readily admit that this only works because we (in general) don't have many BULK child scenarios with many thousands of children/grandchildren. If we did, our UI would become slow. In the few instances of big data, we've been able to deal with it effectively through adding Paging to our Grids and TreeLists.

I also readily admit that it would equally work well (and perhaps be simpler) to break up the objects and do more ad/hoc fetching child stuff as needed with separate objects. This is more explicit and simple for a new-comer dev to understand, learn, and maintain. And it probably works nicely with the modern async Blazor SS UI too.

So summary is think about HOW MUCH data your are fetching at once...along with your UI experience...when you are thinking this through.