How and if you create complex views?

Question

My application is not all complicated. It extracts one object from the web service, edits it and sends it back. The essence itself is quite large and has some associations and several dozen properties. Think of it as a large document (this is actually a document).

I was thinking of creating my application using several nested views. Thus, I have one view and viewmodel for the whole entity, but it contains several views and viewmodels for various properties. Is this a good approach? Or will I face many challenges in the future?

Optional: how to connect them? Do I bind Datacontext of nested views to "entities" ("real" objects from the domain) or ViewModels created by the so-called "parent" ViewModel?

Should I use an MVVM environment such as MVVM Light, Prism or Caliburn.Micro?

Answer 1

If you have one view for a document object or several subviews for a document object, they should all share the same document object. If this is just a small application, then a single view representing a document object may be acceptable.

However, case can also be applied to break an entity into its component parts. This will allow you to create more manageable models for each part. In this case, you will want to use the pub / submodule to traverse the object as it is updated, so that each component is updated by the last entity, if any of the other components modifies the object.

If you decide to go with subviews, then the MVVM structure will simplify management. However, even if you go from one big perspective, the MVVM infrastructure will still take care of the great basic plumbing for you.

I used all three MVVM frameworks that you mentioned, and would recommend going with Caliburn.Micro or MVVM Light. Prism can be a little overwhelming and has a much steeper learning curve.

EDIT

Based on your additional information with the assumption:

• A document object consists of several complex properties.
• Each (most) of these complex properties is a subset of information that can be edited as you wish, i.e. document metadata, information about the author of the document, etc.

Then you could do something line by line:

• Create custom controls for each complex property, which is a subset of the document object. Each user control can have its own ViewModel with logic for editing data.
• Create a basic view (shell) and layout where each user control will be inserted; use ContentControl to container each of these user controls in the command console. Shell ViewModel will be responsible for entering various user controls into each of the ContentControls.
• Create a controller that will do the hard work for the document object, i.e. get a new one, upgrade, etc.
• When any of the user controls changes the data, send it back to the controller, which will update the document object and then transfer the new object to everyone; here you will use the pub / submodule.

It really doesn't matter if you go with Caliburn.Micro or MVVM Light; they both provide a good base for basic plumbing. Go with what is convenient for you.

Answer 2

What do you get from composite models? Are these properties that you want to wrap in separate viewing models really complicated? As in the case, will there be scenarios when you need a bit of more complex modifications / processing, say, MainViewModel.PropertyX ?

If your properties come down to simple values ​​that you can set or not, introducing new view models for them sounds too far away. Keep it as simple as possible.

However, if it makes sense to edit parts of your document out of context (for example, away from the document from which they come, for example, address information), or several sets of similar fields, then it may be worth wrapping them in a general view model. Save you some redundant work.

Prism, MVVM Light ..?

If your application is as simple as several kinds of viewing models, I would stay away from Prism. This is a rather heavy and rather complex structure. On the other hand, MVVM Light can be a worthy idea, even for the sake of learning.

Edit:

Given that your model is quite huge, it makes sense to separate it. I also suggest creating dedicated view / view pairs for objects that consist of your main entity (document). Linking to models may seem attractive, but more often than not you will regret this decision. Simply put:

• a shared view model for objects where it makes the most sense (it can go with everyone, but usually it is a call of judgment - "Do I really need a new view model for this object that displays a single-row property?")
• Separated views corresponding to model types.
• main view model (document) displaying models with partial representation as binding properties
• main view partial views of DataContexts for partial viewing of models taken from the main one.