Response to Ward Bell’s Review of Advanced MVVM

Ward Bell recently published a very thought provoking review/critique of my book Advanced MVVM.  In his review he dished out a compliment sandwich, with a meaty middle of constructive criticism.  I appreciate his positive feedback, and even more so the critical feedback. However, there are a few things in his post that I would like to speak to, since I disagree with some of what he said.

While planning the book, I had to make some decisions and compromises.  My overarching goal was to elucidate the complex interactions that can occur between Views and ViewModels.  I wanted the book to be brief, packed with solutions to recurring problems I’ve seen people asking about on the Web, introduce some interesting new material, and to have minimal overlap with my article about MVVM in MSDN Magazine.  I consider that MSDN article to be “part one” and the book to be “part two” of some unofficial series that I write about MVVM over time.

Another goal was to keep the BubbleBurst demo application understandable to a wide audience.  I made a point of not applying design patterns to everything that could be formalized, because that would just distract the reader from what I wanted to teach them.  Now that you have some of the back story, let’s continue.

Ward’s four main points of criticism are that my book does not cover testing, the data model, dependency injection (DI), or event aggregation.  Since my MVVM article showed how to write tests for the ViewModel layer, I did not cover it in the book.  I know that the examples in that article are not the end-all-be-all final solution to testing ViewModels.  There are certainly a million other important topics that could be discussed to no end about it.  But writing a book about unit testing was not what I set out to do.  I wanted to focus on complex interactions between Views and ViewModels, period.

I’ve had quite a few people ask why the book does not talk about using Model objects.  Aside from the fact that I covered it in the MSDN article, there are two reasons.  First, I wanted Advanced MVVM to focus on the complexities that can arise between the View and ViewModel layers.  That’s why I wrote the book.  Second, working with Model objects is not all that difficult, in my opinion.  When working on an MVVM app, I never find myself solving difficult problems related to the Model, once those classes exist.  That’s the easy part.  Why bother writing about the easy stuff in a book labeled “advanced?”  The hard part about Model objects is designing them, and my book certainly was not intended to be about domain modeling.  Also, the fact that the BubbleBurst application, which is the demo app discussed in the book, has no Model objects, made it even easier to elide the topic…

Moving on to Ward’s other points of critique, let’s talk about dependency injection.  Or, let’s not.  I chose the latter option in my book.  Why?  Dependency injection is a very important and popular topic, so it would certainly be justifiable to discuss it in a book about advanced MVVM.  On the other hand, DI is not in any way, shape, or form part of MVVM.  The two can be used together very effectively, but they are orthogonal practices.  If I wrote a book about DI, would people expect me to include a chapter about MVVM?  I highly doubt it. Like I keep saying, I wanted Advanced MVVM to focus on complex interactions between Views and ViewModels.  The point of the book was not to show how to use every cool, popular, useful technique and pattern.  Advanced MVVM is focused like a sniper on the head of some evil dictator, just waiting to fire a shot.  One shot, one kill.  One focus, one book.

Ward’s other main point of contention is that I didn’t write anything about event aggregation.  He’s correct, I did not.  I certainly could have, but that topic is irrelevant to the focus of my book.

In conclusion, everyone has their own opinion on what a book about “advanced” MVVM should/must contain.  I appreciate guys like Ward, who respectfully disagree with my opinion and voice their own interesting thoughts on the matter.  Perhaps all of this feedback will inspire me to write another book about MVVM!

Advertisement

Control input focus from ViewModel objects

One of the pain points in MVVM development is controlling input focus from ViewModel objects.  A common scenario is when a validation error occurs, and focus needs to move to the control that is bound to the property in error.  This makes it easier for the user to immediately fix the validation problem.

A while ago, Dr. WPF shared a solution to the WPF Disciples that involves hijacking the VM’s IDataErrorInfo implementation and doing some hacky magic that results in focus being sent to the correct control.  While a brilliant solution, I preferred finding a more formal, less hacky solution.  This blog post presents the implementation that I’ve thrown together, with help from the WPF Disciples over the past few days.

In a ViewModel object, you must implement my IFocusMover interface.

public event EventHandler MoveFocus;

void RaiseMoveFocus(string focusedProperty)
{
var handler = this.MoveFocus;
if (handler != null)
{
var args = new MoveFocusEventArgs(focusedProperty);
handler(this, args);
}
}

The MoveFocus event should be raised when the VM object determines that input focus needs to be sent to the control bound to the ‘focused property.’  For example, if the FirstName property of an object is deemed invalid, you would call the RaiseMoveFocus method, passing “FirstName” as the focused property argument.  In the demo application, this results in the TextBox whose Text is bound to the FirstName property to get input focus.

Now let’s shift our attention to the View to see how a control is configured to be able to receive focus.  The only thing you must do is use a custom Binding object that I made, called FocusBinding.  That class relies on Philipp Sumi’s BindingDecoratorBase class, which allows you to create a custom Binding that can override the all-important ProvideValue method (inherited from MarkupExtension).

public override object ProvideValue(IServiceProvider provider)
{
DependencyObject elem;
DependencyProperty prop;
if (base.TryGetTargetItems(provider, out elem, out prop))
{ FocusController.SetFocusableProperty(elem, prop); }

return base.ProvideValue(provider);
}

You use the FocusBinding in XAML like this:

<TextBox

Text=”{jas:FocusBinding Path=FirstName, ValidatesOnDataErrors=True}”

/>

The ValidatesOnDataErrors property setting is not required, but is used in the demo app to enable support for validation via the VM’s IDataErrorInfo implementation.  All controls bound to VM properties that can be “focusable” use the FocusBinding, instead of a normal Binding.  When the VM raises its MoveFocus event, the control whose FocusBinding’s Path references the ‘focused property’ will be given input focus.

You can download the source code here.  NOTE: Rename the file extension from .DOC to .ZIP and then decompress it.  Feedback is welcome!

Handel Keyboard Suite #2 – Allegro

Every once in a while I post a recording of myself playing a piano piece that I’ve been practicing.  This time I’m performing the Allegro from Handel‘s second keyboard suite.  The recording quality is not ideal, since I never invested in real recording equipment and software.  For those of you who like Baroque keyboard music, I hope you enjoy it!

Handel Keyboard Suite 2 – Allegro

Another review of Advanced MVVM

A few days ago I received a comment from someone named Joe on my blog.  He was expressing concern over several aspects of my book Advanced MVVM, including the fact that it is written about a relatively simple game, not something more complicated.  After Joe read the book his apprehensions about it disappeared, and he kindly left me this comment:

Josh,

Ok, after reading your book, I have to say “Wow!” Not only have you managed to help me understand some of the frustrations I had with MVVM development, but your book also made some good points (which I shared with my development manager) and reinforced with real examples of issues I faced working on a project using that pattern.

I was very (pleasantly) surprised reading your take on the code-behind vs. NO code-behind mentality. I myself prefer the middle ground, but for some time was forced to do the latter. Yes, it did create several layers of very difficult to follow, understand and maintain code; from your notes and my examples, I was able to reach a compromise on how we should utilize ‘code-behind’.

Now, an interesting story –our architect chose the MVVM pattern after reading your article in MSDN in 2009. However, they chose to enforce “no code-behind” at all for the sake of testability.

The book is awesome; if you can mix MVVM with Prism and come up with a nice 300+ page book with some nice distilled information like that, I’d a) like to help write it; and b) shell out at least $50.00.

Cheers!

Joe

P.S. you’re right, there is no “Silver Bullet”; however, it would be nice to have some guide or set of documentation as to what works well when and where, especially when certain design patterns are applied to solve a problem.

It sounds like Advanced MVVM has another happy customer! 🙂

The first review of Advanced MVVM

I’m thrilled to announce that Tim Heuer, one of the top Silverlight community members, evangelists, and Program Managers at Microsoft, has published a review of my book Advanced MVVM.  He gave the book a very solid thumbs-up, which made my day!  If you’re interested in reading what Tim had to say, here’s the link: http://timheuer.com/blog/archive/2010/03/04/advanced-mvvm-book-for-silverlight-wpf.aspx

Thanks Tim!