MVVM Survival Guide for Enterprise Architectures in Silverlight and WPF: If you're using Silverlight and WPF, then employing the MVVM pattern can make a powerful difference to your projects, reducing code and bugs in one. This book is an invaluable resource for serious developers.

The book acknowledges the plethora of contradictory, even misleading, generally available information on using MVVM with WPF (I don't use Silverlight). Against this background, its objective approach helped clarify my thoughts, so that I am delighted with what I have been able to put into practice.A few other reviews have mentioned the number of external references to topics that are out of scope. I bought the book specifically to address MVVM/WPF integration, so I have not minded them at all. For me, it has a specific focus for which it caters admirably.

I've owned this book for several years now and have implemented MVVM in real world WPF projects.The first few chapters explain why you'd actually want to use MVVM by contrasting the pattern with predecessor UI patterns using several code based example. This provides a solid and convincing justification for the pattern.The author then then goes on to build a more substantial application conforming to industry best practices and explaining his choices throughout.I was initially skeptical of the use of the MVVM lite library but when it came to the reality of implementing an MVVM project without MVVM lite you'l be forced to either write your own version of the libraries functionality so you might as well use it.Its a shame the author mentions Silverlight first in the title because that dead tech will probably put people off but there is very little Silverlight this is a solid WPF book.

Good stuff

Lots of words have been written about MVC, MVP, and MVVM among other programming patterns and how they are all designed to help the developer create applications quicker that are more maintainable. If you are working in XAML with WPF or Silverlight, then MVVM is the defacto standard for application development. What I appreciated in this book was that this is the assumption that is made and it isn't an apologetics title on why you should pick MVVM as your design pattern. I hate when a book spends the first half trying to sell me on the pattern... I'm already committed to it that is why I buy the title! The authors here recognize that and don't waste my time trying to convince me why I should be using the pattern.The book starts out with a bit of history by talking about monolithic application design and walks the reader down memory lane touching on RAD, MVC, MVP, and finally bringing us to MVVM. I thought that was really cool. For someone not familiar with this heritage, it is good to learn it as it gives some context about MVVM and how we got here. What I also thought was good is that the same example application is used to describe each model with a discussion of how the application would be implemented under that model. That really highlights the differences and helps the reader understand the drive towards MVVM.But let's face it; this book is about MVVM and how to successfully use it in 3-tier applications at an enterprise-ready level. And that is important... because it means the details are there to help the developer identify the dark corners of application development that take an effort from average to enterprise. (The book covers WF and workflows... In an MVVM book! That is how detailed it is!)At over 450 pages, the book is crammed full of useful information. The reader is literally walked-through the design and development of a 3-tier enterprise application as each chapter introduces a new concept building on the previous one to add layer after layer of functionality. Along the way, all the challenges of complex application development are covered as well as how to structure for maintainability. The pain points in MVVM are talked about where applicable as well as ways to mitigate that pain. I've been writing apps in the MVVM pattern for years and I was still able to get a lot from this book.Is this for absolute beginners? Maybe not... things move fast and tackling a big app right out of the gate is probably a setup for failure. But for someone that has some familiarity with C#, WPF, and/or Silverlight (and MVVM or even MVC/MVP) this book will be great. I found that I was relying on some of my knowledge from outside the book to help understand and grasps the concepts inside the book but I chalk that up to just the fact that MVVM and enterprise application development are complex topics. It is impossible to present every facet of knowledge in one place. Plus, even though the pattern is well defined, there is a lot of wiggle room and space for interpretation.Overall, I think that for people working in WPF or Silverlight and that know some MVVM, even at a beginner level; this book will give them tons of useful information. Even if, like me, you've been doing it for a while, I think there is still a lot of information to gain. I have gone back a few times to refer to a section while working on projects. I've had this book for just over 2 months now and it has proven to be a great guide to getting deep with MVVM and then again as a reference to help refresh my memory as I tackle projects.

The job of the reader is to understand what the presentation design patterns define with respect to purpose and principles and how technologies and real world environments can enhance or limit the purpose without violating the principles. While the name of the game is facilitation of development via SoC, performance improvements can be gained with the use of the right design and complementary technologies.This book really covers all the relevant topics, most are discussed in detail and some are just alluded to for further investigation. The authors show you one way of doing something, and then improve upon it later. This is a book designed to teach students (very heavy on the sample code), not to tell experienced developers what they already know. It would actually serve as a great syllabus in a course.Chapter 1 tackles the monolithic approach but it also criticizes the RAD approach. If one didn't know better you'd think RAD was always the way to go, so I'm happy to see it brought down a notch. MVC and MVP are historically examined and differentiated but not bashed; the benefits and limitations are simply put out there. They don't muddy the waters with too much MVVM up front. Takeaway sections can be referenced if you begin to second guess your design pattern of choice.Chapter 2 makes it clear why MVC's strong presence is due primarily to the lack of web client technologies with strong declarative binding support (with the presence of frameworks such as KnockoutJS and AngularJS, the MVVM pattern is gaining wider support). Supporting patterns such as Property Object and Command are introduced along with their technical implementations and from what need they arose.Chapter 3 can be quickly skimmed if you don't intend to implement the ongoing sample project.While in Chapter 4 I was surprised to not find the phrase "RIA Services" in the entire book. This was such a good decision, it is much better left to another book entirely; any brief samples would only be confusing. This chapter has a lot of value in terms of putting you in the right frame of mind regarding persistence ignorance; it just tends to force you into a UoW pattern, which is good. But I don't see too much value in DDD over Table Module for your data object model since for the most part your data object model will mimic the database tables. I thought DDD was for your logical entities... yet nevertheless the authors' advice is applicable in principle.In Chapter 5, the use of attached behaviors to map multiple control events to one or more commands is impressive.Chapter 6 left me with a bitter taste in that I consider the View Model to be the context of a View, AKA "Region" of the page, synonymous with an ASP.NET user control. I don't consider the View Model to be a context for Data Templates. That's equivalent to saying that each item in a listbox is a View, that's why it's called a DATA Template, and listboxes have ITEM Templates, not VIEW Templates. I don't like the great gap in scope between a classic View and a View for each item in a collection. I am accustomed to exposing data objects directly to Data Templates, as collection properties on the View Model. View Models contain and represent much more than just database records, a View Model:* contains cross data entity business rules related to the View* communicates with other View Models (Event Aggregation) to enforce cross View business rules* defines commands to object context logic* is not a database record (which for the most part are only objects because that's how .NET works, they are more relationally defined than object oriented)* maps to one or more logical entities that provide its functionality* pulls together multiple data objects into a well prepared context for a View* is not a data objectThe authors do not contrast the difference between a data model and a logical object model. Take a Product Manager class as opposed to a Product class, their purpose couldn't be more different and only one gets persisted. How often do you have a data object that serves as the entire context of a classic View? It's typically a collection for a list control or two with surrounding menu context, so the argument that the View Model would require the data model's properties to be redundantly defined on it, isn't considering that it's usually only exposing a couple of collections.If you wouldn't think to navigate to a View or establish it as a named region, then it doesn't need a View Model.If you understand my point of view as well as the authors', then you're on the right path, regardless of which approach you choose to implement.Chapter 7 will save you lots of time on the learning curve, as any WPF or Silverlight purest will tell you.Chapter 8 was very interesting since I've spent a lot of time trying to figure out how WF fit with a MVVM style application. The more you play with it the more you realize that your application probably doesn't even need it (it fits best in an automated distributed system), although it's good to know it's there if you do. The absolute lack of guidance from Microsoft on this subject is depressing.Chapter 9 is excellent. Validation is validation but with so many options you want to know how to pick the appropriate approach.Chapters 10, and 11 are pretty much what they say they are, but you're getting into the fringe.It's too bad custom controls weren't discussed in any detail, since the MVVM pattern applies just as well, and offers the chance to highlight the theoretical aspects of MVVM in a much more compact scenario.If you're relatively new to WPF and Silverlight using the MVVM pattern, please realize there are supporting patterns, principles, and frameworks that make it practically possible. Chapters 4, 5 and 6 are the theoretical meat of this book, re-read them if necessary. You don't have to memorize patterns and principles, just develop a list of questions to ask yourself in the design phase.Writing testable code often automatically has you asking all the right questions, which BTW this book does a superb job of doing.