Question

My application is not all to complicated. It retrieves a single entity from a webservice, edits it and sends it back. The entity itself is rather big and has some associations and a few dozen properties. Think of it as a big document (it actually is a document).

I thought of building my application up using multiple, nested views. So i have one view and viewmodel for the complete entity, but this contains multiple views and viewmodels for the various properties. Is that a good approach? Or will i face a lot of problems in the future?

Additionally: How would i wire them up? Do i bind the Datacontext of the nested Views to “entities” (“real” objects from the domain) or ViewModels created by the so-to-speak “parent” ViewModel?

Should i be using a MVVM framework such as MVVM Light, Prism or Caliburn.Micro?

Answer 1

Whether you have one view for the document entity or several sub-views for the document entity, they should all be sharing the same document entity in the end. If this is just a small app, then a single view that represents the document entity may be a decent approach.

However, a case can also be made to break the entity down into its component parts. This will allow you to create more manageable models for each part. This being the case, you’ll want to use a pub/sub model to pass around the entity as it is updated so that each component part is updated with the latest entity if any of the other components modify the entity.

If you decide to go with the sub-views, then an MVVM framework will make it easier to manage. That said, even if you go with one big view, an MVVM framework will still take care of a lot of the basic plumbing for you.

I’ve used all three of the MVVM frameworks you’ve mentioned and would recommend going with Caliburn.Micro or MVVM Light. Prism can be a bit overwhelming and has a much steeper learning curve.

EDIT

Based on your additional information with the assumption of:

• Your document entity is comprised of several complex properties.
• Each (most) of these complex properties represent a sub-set of information that can be edited on their own merit, i.e., Document Metadata, Document Author Information, etc…

Then you could do something along the lines of:

• Create user controls for each complex property that represents a subset of the document entity. Each user control can have it’s own ViewModel with logic for how the data can be edited.
• Create a base view (Shell) and layout where each of the user controls will be injected; use a ContentControl for the container of each of these user controls in the Shell. The Shell’s ViewModel will be responsible for injecting the various user controls into each of the ContentControls.
• Create a controller that will do the hard work for the document entity, i.e., get a new one, update, etc…
• When any of the user controls modify the data, send that back to the controller which will update the document entity and then broadcast the new entity to everyone; this is where you’ll use the pub/sub model.

It really doesn’t matter if you go with Caliburn.Micro or MVVM Light; they both provide a good foundation of basic plumbing. Go with whatever you feel most comfortable.