CODEWITHSUNDEEP
c#wpfmvvm
user604613
user604613

Reputation:

How and if to build up composite views?

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?

Upvotes: 6

Views: 1790

Answers (2)

Metro Smurf
Metro Smurf

Reputation: 38335

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.

Upvotes: 2

k.m
k.m

Reputation: 31454

What will you gain from composite view models? Are those properties you want to wrap in separate view models actually that complex? As in, will there be scenarios when you will need bit more advanced modifications/processing of let's say, MainViewModel.PropertyX?

If your properties boil down to simple values that you might set or not, introducing new view models for them sounds like going a bit too far. Keep it as simple as possible.

However, if parts of your document make sense to be edited out of context (as in, away from document they come from - think for example address information), or there's multiple sets of similar fields, then it might be worth wrapping them in common view model. Will save you some redundant work.

Prism, MVVM Light..?

If your application is as simple as few views nad view models, I'd stay away from Prism. It's rather heavy and fairly complex framework. MVVM Light on the other hand might be decent idea, even for the sake of learning it.

Edit:

Considering that your model is quite huge, it makes perfect sense to split it. I also suggest creating dedicated view model/view pairs for entities that your main entity (document) consists of. Binding to models might sound appealing, but more often than not you'll find yourself regretting that decision. To put it simple:

  • separated view model for entities where it makes most sense (could go with all, but it's usually judgement call - "Do I really need new view model for this entity exposing single string property?")
  • separated views matching view models
  • main view model (document) exposing partial view models as bindable properties
  • main view setting partial views DataContexts to partial view models taken from main one

Upvotes: 2

Related Questions