originally posted by Josh Smith: (link) - please comment at original post
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!
Remember to please comment at original post: (link)