What makes MVVM uniquely suited to WPF?

DataBinding, commands, control templates and XAML.

DataBinding, commands, control templates and XAML. Without one of these, MVVM would be a lot harder, if not impossible. Take ASP.Net for instance, it has the ASPX part (which for the sake of the example is equivalent to XAML), it has data binding, but it doesn't have commands or control templates, so MVVM is not possible there.

In WinForms, we have databinding, and that's pretty much it, so not possible either.

– Reed Copsey Oct 5 '09 at 17:43 For 2 reasons, DataBinding (in MVVM is done through XAML) and ControlTemplates. Without the latter, editing / creating our own control would be code-bound, making MVVM more difficult when working with user created controls. – Carlo Oct 5 '09 at 17:45 Databinding doesn't have to be done through XAML, and there's some who prefer to split it from the XAML.

While creating code UI is harder than XAML, it is possible, and doesn't affect MVVM use. And I think data templates are more relevant to MVVM than control templates. – Cameron MacFarland Oct 5 '09 at 23:45 It does not HAVE to, but the point of MVVM is making it through XAML, so the actual code can run independently from it XAML, to unit test, for instance.

It's a lot better to not do any binding in the code side, also to not use events (use Commands instead), that way your controls are not bound to the events in your code. – Carlo Oct 5 '09 at 0:43.

In short: it's the data binding. Per the Data Binding Overview from MSDN: If the binding has the correct settings and the data provides the proper notifications, then, when the data changes its value, the elements that are bound to the data reflect changes automatically. Data binding can also mean that if an outer representation of the data in an element changes, then the underlying data can be automatically updated to reflect the change.

For example, if the user edits the value in a TextBox element, the underlying data value is automatically updated to reflect that change. If you set your XAML up correctly, you only have to interact with your user interface using the viewmodel. WPF takes care of updating the UI when the viewmodel changes, and updating the viewmodel when the UI changes (ex.

User input).

Mmm - I don't feel that Data Binding is enough, in and of itself, even though this is the main touted feature. Things like Truss would allow MVVM for any . NET technology if it was just about data binding... (I do agree that it's an important building block, just not the only one).

I was hoping for other, non-databinding, features that are critical. – Reed Copsey Oct 5 '09 at 17:42.

I think commanding support (ICommand) in addition to great data binding capabilities makes it suitable for WPF and Silverlight.

I've implemented MVVM's cousin pattern Model-View-Presenter in MFC, WinForms and even MATLAB. I agree with the original post: WPF facilitates data binding very nicely, but you can utilise the concepts in other platforms (albeit with more code). Reading John Grossman's blog, the real distinguishing difference is that the user interface is to be written in a different language than the business logic.

The ideal seems to be that the UI development is performed by "designers" not programmers. This is the area that WPF is unique - I don't know of any other development environments that work towards this ideal. (Mind you, I've never worked on a big enough team to warrant dedicated UI designers.

I can't say whether this ideal is actually achievable).

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.