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!

11 Responses to Response to Ward Bell’s Review of Advanced MVVM

  1. Glenn Block says:

    He had one more point about the refactoring of the 300 line code ViewModel. And your answer is?🙂

    Glenn

  2. Josh Smith says:

    I don’t have a response to that. I’ve got nothing against a 300 line VM class. If others prefer to break them apart, that’s fine by me, but I’m not going to worry about following other peoples’ rules.

  3. […] Response to Ward Bell’s Review of Advanced MVVM (Josh Smith) […]

  4. Ward Bell says:

    Hi Josh – Thanks for responding to my post. I’d like to clarify on your blog if I may.

    I didn’t know this book was a sequel to an MSDN article which, shame to say, I have not read. To know of that context would have helped. Btw, I just skimmed your book again and I don’t find a reference to the MSDN article; maybe I missed it.

    To write is to make choices: what to include what to leave out.One must respect the author’s perogative … and I do. It was the fashion when I was in grad school to roast an author for his omissions. That’s easy game … and I won’t play it.

    I am satisfied by your reasons for skipping Model, DI, and EventAggregator. I hope my commentary remains useful.

    I felt then … and feel now … that these topics deserves some attention … more than a mention .. in an “advanced book” and I tried in my remarks to suggest how such attention might have influenced the sample or be pertinent in a LOB application. But I appreciate your decision to hold them at bay while you pursued your main themes.

    You didn’t need a model for BubbleBurst. That made BubbleBurst a great choice for exploring View / ViewModel dynamics without the encumberance of a Model. I buy that completely … and I think some of your critics missed the point.

    In spot-lighting Model, I was talking about what comes next after BubbleBurst … what happens as you move from simple game to a richer business application. I suppose I was looking toward the next chapter, the one not (yet) in the book … which makes my criticism not entirely fair.

    You say “working with Model objects is not all that difficult … When working on an MVVM app, I never find myself solving difficult problems related to the Model, once those classes exist.”

    My experience is quite different. For example, I encounter much angst and argument over (a) whether model objects should be bound directly in the view or wrapped in a ViewModel, (b) what to do about INotifyPropertyChanged and validation, (c) whether the persistence machinery (query and save) should be directly accessible to the ViewModel, and (d) whether that machinery is part of or independent from the Model itself. Ones choices reverberate across the application. It’s not a small matter.

    The genius of BubbleBurst is that you can avoid Model distractions while concentrating on View / ViewModel interaction.But when the time is ripe, you’ll find much to discuss.

    Along the same lines, I feel readers should know that they can decouple Views and ViewModels with DI and EA rather than have these components hold direct references to each other as they do in BubbleBurst. But … and I think I said so … it makes good sense to bring them into the story later … in chapter X … after you’ve established the fundamental relationship between View and ViewModel.

    I think you are on less firm ground about testing. I wasn’t looking for “a book about unit testing” and I was expecting you “to focus on complex interactions between Views and ViewModels,”

    However, it was you who asked the question “Why go to the trouble of separating View from ViewModel?” and it was you who acknowledged that testability is one of the primary benefits of the pattern. You need not have re-explained how to write unit tests … especially if you covered that in your MSDN article. But I think it is reasonable to have included some tests in the code-base even if you didn’t discuss them. Such evidence would reinforced the significance and importance you attach to testing.

    Now in practice I rarely see unit tests of MVVM. If MVVM is only justified on grounds of testability, we should call B.S. on the pattern and almost everyone who practices it. Bad enough to distort an architecture, for the sake of testability … but to add insult by omitting the tests is beyond the pale.

    I happen to think that View / ViewModel separation is an application of Bob Martin’s SOLID principles. The benefits of these principles are realized whether or not you write automated tests. You get more benefit with automated tests … but you get benefit either way.

    Finally, Glenn noted that you neglected to mention the refactoring exercise which occupied perhaps half of my post. Unfortunately, he described this as a re-factoring of the ViewModel. I have “nothing against a 300 line VM class” either … and I don’t have any fixed rules about the size of a VM class.

    But I didn’t refactor your ViewModel. I refactored your View. And that does matter – it matters a lot – when it comes to applying the MVVM pattern.

    “Zero code-behind” is not an MVVM axiom; “Minimal code-behind” is!

    A View that has 300 lines of code-behind is a view in trouble. I’m curious if you agree. You offered one standard for code-behind: it must be “logic scoped to the view”. I don’t know what “scoped to the view” means and I said so.

    I offered an alternative standard – “no conditional logic in the view” – and backed it up by refactoring one of your Views to conform to that standard. I’m curious to know your thoughts.

    Where does this leave us?

    I am comfortable with your choices for this book … and I continue to recommend it. I had my own idea of what “advanced” means and I now see that I was anticipating chapters that have yet to be written.

    I trust no one reading our exchange will feel compelled to choose sides … because there are no sides. This is a conversation. It starts with what you actually wrote and journeys forth from there.

    Fondly,

    Ward

  5. Adrian says:

    Currently reading the paper version… I am appreciating the focus.

    Please write another book. Maybe with the title MVVM on Steroids.

  6. Ahsan Sharafuddin says:

    Thanks to both Josh and Ward for the good discussion. I agree that automated unit tests in the code base would be a great inclusion even if it is not mentioned in the main text. Finally, many thanks to Josh for yet another great writing. Regards. — Ahsan

  7. Josh Smith says:

    @Ward – Your points are well taken. I can see how including some unit tests in the code base would have been very useful and educational. I am definitely not saying that testing is “the reason” for using MVVM; it’s just one of the possible benefits of using the pattern.

    @Adrian – Thanks! Another book is definitely something I’m considering…

    @Ahsan – I’m glad you enjoyed it. Thank you.

  8. Dan says:

    Nice. Cant wait to read it. Do you include anything about mediator in the book? Or should we be using a tighter event approach?
    Thanks Dan

  9. Josh Smith says:

    Dan,

    I don’t discuss Mediator in the book, but that’s not an indicator of how you should implement eventing in your app.

    Thanks,
    Josh

  10. Raul says:

    If you were to do an “MVVM on steroids” I would sooo buy that. I would love to see detailed explanation of a complex app.

  11. JD says:

    I agree with everyone else. I would like to see MVVM in action in a complex Master-Detail scenario.

%d bloggers like this: