I've had several questions about when and why to use M-V-VM versus other approaches. The obvious purpose is abstraction of the View, reducing the amount of business logic or glue code stuck in code-behind. All tasty goodness abstractly, but here's another concrete advantage: the ViewModel is easier to unit test than code-behind or event driven code. The ViewModel, though it sounds View-ish is really more Model-ish, and that means you can test it without awkward UI automation and interaction. If you've ever tried to unit test UI code, you know how hard that can be.
Disadvantages? For simple UI, M-V-VM can be overkill. In bigger cases, it can be hard to design the ViewModel up front in order to get the right amount of generality. Data-binding for all its wonders is declarative and harder to debug than nice imperative stuff where you just set breakpoints (though if you have lots of events running around, it may not be much different).
Data-binding performance is quite good, but it does tend to create a lot of general book-keeping data around. For awhile, we were adding a MultiBinding to every object we created. Loading a large file this meant 50,000 of them. In the WPF build we were using they were nearly 2K per...meaning the Bindings were heavier than the objects being bound. In this particular case I replaced the all the Bindings with a single static callback and saved nearly 100MB...! Normal UI won't create nearly so many bindings, but the perf is something to keep an eye on.
文章来源:
http://blogs.msdn.com/johngossman/archive/2006/03/04/543695.aspx