0

I think I have a pretty good understanding of the MVVM design model, however I have a quarm with it in regards to WPF, Command bindings and how we are meant to use them.

To bind commands to the XAML directly we are meant to implement the ICommand interface within the ViewModel. Now, the ICommand interface is part of the PresentationCore.DLL, which, correct me if im wrong is part of WPF not the base .NET framework.

Isnt the whole point of the ViewModel and Model that it should be totally UI independant? For example, if I implement ICommand in my ViewModel and use it as a data context in order to bind commands from the XAML, isnt my ViewModel then dependant on the WPF frame work (in particular the PresentationCore.Dll).

What I mean is, if I was to go and try to use my Models and ViewModels in lets say a Windows Forms environment, I would have to reference the PresentationCore.DLL even though I shouldnt need it because im using Windows Forms not the WPF framework.

This seems a bit odd to me, am I missing something here? Is there another way I should be doing it to keep my Model and ViewModel totally UI and UI Framework independant, but still be able to utilise the Command binding in XAML?

Thanks in advance!

Dave Clemmer
  • 3,741
  • 12
  • 49
  • 72
Aaron Murgatroyd
  • 1,506
  • 19
  • 22
  • The only solution I have for myself at this point is to create two view models, have a XXXViewModel and an XXXViewModelWPF which inherits from XXXViewModel and contains all the ICommand related stuff, then the XXXViewModelWPF classes simply become WPF only. Is there a better way? Thanks – Aaron Murgatroyd Jul 14 '12 at 06:20

4 Answers4

1

The point of MVVM is to have the view just be a view, and nothing more. Putting ICommands into the view model helps this as it pulls the code away from the view. Where you will run into problems is if you have to access something on the view that is not a dependency property, which means you can not bind to it.

jle
  • 9,316
  • 5
  • 48
  • 67
  • Thanks for the answer, so my interpretation of the MVVM model is incorrect? the point of the ViewModel is not to abstract the View from the Logic, but more to remove all code from the view. So if I was to move my program to Windows Forms, I would have to re-write the ViewModels AND the Views, not just the Views? I thought the point of the design pattern to limit rework needed when the UI design changes? – Aaron Murgatroyd Jul 14 '12 at 06:24
  • MVVM is specifically designed for WPF. I don't know how well it would work with Windows forms. I agree about limiting rework, but because WPF and Winforms are so different, I don't know how easy it would be to switch even with no ICommmand in the viewmodel – jle Jul 14 '12 at 06:33
  • Ok thanks, I really dont see the problem with using my ViewModels and Models in a Windows Forms application except for the ICommand implementation at the moment. A Windows Forms control for example could contain a reference to the ViewModel and hook its OnPropertyChanged event to invalidate itself as needed. The Paint message would simply paint as required by the current state of the ViewModel. I think im going to use my comment in the original question post idea, can you think of any other way? – Aaron Murgatroyd Jul 14 '12 at 06:37
1

I also had this kind of problem but not in wpf but in POCO classes. What i did was I created two partial classes in two different assemblies. Like you create one partial class which is not presentationcore.dll dependent in your VM project and create its partial class in another assembly(say WPFVM) which implements ICommand stuff. Now for Winforms stuff add only VM project reference to View project and for WPF stuff add references of both VM and WPFVM to the View project. I hope this will help.

yo chauhan
  • 12,079
  • 4
  • 39
  • 58
  • Thanks ethicallogics, I have decided to do this already, except, instead of using Partial classes im going to create a descendant class for each ViewModel called XXXViewModelWPF which has the ICommand properties on it. As you said, this way I simply do not incalude the XXXViewModelWPF in my Windows Forms implementation! Its a great idea, thanks. – Aaron Murgatroyd Jul 14 '12 at 06:41
1

In my opinion MVVM is very popular with the WPF, Silverlight because it naturally fits into it. The data binding concept in the XAML allows the Views & ViewModels to be bridged using a single property which is the DataContext. As no longer your logic is tied to controls, you get better testability, design-code separation and maintainability. You may be able to implement the MVVM pattern in other places also, but in WPF and Silverlight, it fits so easily due to its data and command binding support. I have read somewhere that, Don't take patterns religiously. They were made to make your life simpler rather than giving you more problems while following it. For Winforms i think there are better patterns, If you are focusing in reusing the business logic, move them out of your ViewModels to seperate classes something like serviceproviders or serviceagents and share them between your Winforms and WPF apps.

Moble Joseph
  • 647
  • 4
  • 14
  • Thanks Moble Joseph, I guess one could do it that way, but to me that would be a lot more of an inconvenience trying to abstract out all the business logic into separate classes without direct access to the information to be applied for those business rules. All the data would need to be passed in to the classes. I still think my best option is to create descendant ViewModels specific to WPF for the commands, unles im not understanding you correctly? – Aaron Murgatroyd Jul 14 '12 at 06:56
  • So Currently you do your business logic inside those commands ? You don't separate out the business rules to a separate class using some Data Transfer object ? – Moble Joseph Jul 14 '12 at 07:12
  • The logic isnt really complicated enough to warrant that, the program dosnt use a Database as a backend it just has state information for the objects which is stored in the Models, then the ViewModels are responsible for notifying the Views of changes via events (in this case the PropertyChanged event). So yes all the logic for the program is inside the ViewModel, as I understand it, the basic MVVM only accounts for the Model, ViewModel and View anything extra is on top of MVVM? In case your wondering its a Scrabble Board Solver. However the solver code is abstracted out into separate classes – Aaron Murgatroyd Jul 14 '12 at 07:22
1

This has changed in .NET 4.5 compare

jan
  • 1,581
  • 2
  • 19
  • 34
  • Thanks for this jan, I don't know if someone at Microsoft read my comments here and decided to move it, but now it is part of the .NET base framework in system, hurrah! – Aaron Murgatroyd May 19 '13 at 11:18