MV? and WPF, some possible Answers?

Hello Everyone,

So me and a co-worker of mine James Ashley have been discussing UI patterns as they related to WPF and Silverlight and really trying to find the one good fit that covers what people need from a pattern.  We found ourselves discussing not so much the implementation of a pattern to fit the needs, but rather looking at existing patterns and discussing the semantics of what each pattern represents.  They all have their pros and cons like anything in the world does but what we need is one good solid foundation for building WPF applications so that people aren’t trying to stick to an existing purist pattern and giving up something they need or is powerful to make sure they dont break the rules of a pattern.  James Ashley did a great post discussing the differences and utilizations of the different patterns called MVVM: UI design patterns in the wild.  I suggest reading this post first becuase it is a pre-cursor to what I am going to talk about today.  Today I am going to try to provide some opinions on answers to the situation we run into with patterns associated with a technology like WPF.

So first of all in WPF and Silverlight we definitely want to make use of DataBinding.  Its so powerful and robust in WPF that it makes the choice very simple in that we should use it.  So any ui patterns that do not make use of DataBinding should be thrown out to start of with.

So now lets discuss semantics a little but.  MVVM has become a very popular pattern to use with WPF but in my opinion it has a few drawbacks.  All of the patterns include a M for model and a V for View but its that middle object that ends up with drastic changes to a pattern.  In MVVM its a ViewModel.  So what is a ViewModel.  If you think about the semantical term it’s a Model representation of your View.  To me this sounds like it should be a direct description of the View, meaning 1 to 1 field mapping.  If you have a PersonView that has a FirstName and LastName text boxes then in your ViewModel you would have a FirstName property and a LastName property to bind to.  Then your ViewModel would contain a Person object (your model) that would have their properties be routed to through the ViewModel properties.  This code might look something like this.

   16         private Person PersonModel;


   18         public string FirstName

   19         {

   20             get

   21             {

   22                 return PersonModel.FirstName;

   23             }

   24             set

   25             {

   26                 PersonModel.FirstName = value;

   27                 OnPropertyChanged("FirstName");

   28             }

   29         }


So the first thing that people probably notice is that we have duplicated our fields.  This is where the MVVM pattern gets a little sticky.  Why would we want to make our code harder to maintain by duplicating our properties from a Model to a ViewModel.  What we could do is provide binding straight to the model.  Lets say we have our PersonModel but as a property instead of a private field.  We can now specify our fields in our model and also our validation at the model level.  Instead of binding to FirstName, we bind to PersonModel.FirstName.  But if we provide this sort of binding are we now out of the semantics of using a ViewModel since our class no longer directly describes our View?  Also if we bind straight to our model we have to provide validation at the model.  What if different views have to work with different validation rules?  This can be a little tricky with binding straight to our model, but a bit easier with the pure VM way.  in the pure VM way each VM describes its own validation rules, but now once again we have to duplicate our common validation rules accross many VM’s going back to a maintenance problem.  The answer to this is to provide boolean flags for our validation rules in our Model.  Properties are expendable so i do not think it would be bad to have 1 boolean per validation rule.  Then the VM can have the responsibility of configuring the validation rules for the model its working with.  Something like this.

   31         public PersonViewModel()

   32         {

   33             PersonModel.IsFirstNameRequired = true;

   34             PersonModel.IsLastNameRequired = false;

   35         }


So now we have our models containing re-usable fields and re-usable validation rules while our middle object (not a VM at this point?) factilitates pass-through binding to our model and configuration of our rules.  Our middle object would still adhere to the commanding structure described in James Ashleys post.  So our middle object now becomes what i would like to just plainly call a Facilitator.  It facilitates the bindings to the model, it facilitates the configuration of validation rules and it facilitates the commanding to run our non-ui functionality.  It doesnt seem like a ViewModel to me because it doesnt directly describe the View.  It doesnt seem like a Presenter because it doesnt know, nor care about the View and isnt making any decisions on which view should be used.  It doesnt seem like a Controller because it directly utilizes binding.  Do we now have a new pattern called Model-View-Facilitator? (MVF). 

There is another piece to all of this that includes how a View and middle object are tied together.  Some use Dependency Injection so the middle object knows about itself and the View, or Dependency Injection into the View with the middle object, and then there is a DataTemplate scenario.  Regardless of which pattern we use this concept shouldn’t matter.  Generally MVP might be directly tied to the DI injection of a View into a Presenter, but we can use this for many different patterns.  It still all comes back to semantics and trying to figure what we are trying to achieve.  In my next post i will be discussing these different integration points as they relate to the semantics of a pattern and how they can be utilized.

Hope this helps and have a good day!

Comments are closed.