Further reflection on PresentationModel

I'm a big Fowler fan, his "Refactoring" book is one of my all-time favorites, and I used to read his site religiously (somehow it fell off my feed list, you can bet it is going back on).  Anyway, I'm sorry I missed his post last year on PresentationModel.  Thanks to Dirk for pointing it out to me now.

The pattern is very similar to Model/View/ViewModel.  The interesting part is where Fowler started to run into problems:

Probably the most annoying part of Presentation Model is the synchronization between Presentation Model and view. It's simple code to write, but I always like to minimize this kind of boring repetitive code. Ideally some kind of framework could handle this, which I'm hoping will happen some day with technologies like .NET's data binding.

WPF has done exactly that by including a very rich powerful data-binding engine.  Basically, in the past all of these frameworks worked using the Observer or Publish/Subscribe pattern.  In the simplest version the Model publishes change notifications and the View subscribes and updates itself in response to events.  Not only is this code repetitive, but it can be a source of bugs and perf problems.  The data binding engine in Avalon just automates all that work, and provides 2-way binding to boot that minimizes how much work you have to do to push changes from the View back into the Model.  Chris describes this well in the data-binding chapter of their (his and Ian's) WPF book.

Fowler also describes another variation of MVC called Model/View/Presenter.  The difference is super subtle:

Classic MVC doesn't work well with modern rich client tools because they design things so that the view handles all the user events such as mouse and keyboard clicks. In Model View Presenter the view continues to handle these, but then immediately delegates these to the presenter. The presenter then decides what to do with the event, communicating with the domain and the data in the view's controls.

This is another variation of the point I was trying to make about Controller before.  All of these variations exist because while everybody agrees Model and View separation is love, Controller was always the odd one in the trio, and as UI technologies have advanced it has been subsumed more and more into the View or the framework itself.  In Avalon, the controls handle the user events and cause them to trigger Commands, at least as we use them (Avalon still favors event handling "in the view").

Comments

• Anonymous
  January 13, 2009
  Jag talar ofta med kunder och partners som vill använda vedertagna designmönster för att separera ansvaret

• Anonymous
  June 04, 2009
  WPF e il View model, qualche risorsa utile.