In this post I want to show you how to Clean your viewmodel in WPF and create a facade.
We use a facade to get your viewmodel in WPF nice and clean. I want to show you how to get along with the seperation of concerns and how to write simple and testable code with databinding and WPF.
When you want to use a viewmodel for databinding you normally get your public properties on your viewmodel an do a normal binding on your xaml like this:
Setting the datacontext:
and your viewmodel something like:
of course you would give the viewmodel other values and it would grow like hell. Also when you do calculations or CRUD-operations etc. But when your application grows and gets bigger it would be necessary to move some thing into services, providers etc. to get into the seperation of concerns.
Solution I - Services
So lets introduce a service to do some work (a normal calculation with the result of 23 in my example):
And your viewmodel could look like this
Note: Normally you would use dependency injection here to avoid this “new …” call and a link to the direct implementation of the service.
So: Now we have outsourced the calculation and introduced a new service which is doing the work. But this is not a facade. Our viewmodel is still very big (image it bigger than it looks here: There are a lot more properties on it in a real application).
Solution II - Facade
The viewmodel should now get a real facade and only offer the service which is doing the calculation. This makes you more flexible and the viewmodel is like only an interface for the view. Its like a provider for every service (or providers) which contain the information the view needs.
So far until here. What we did is: We are only offering the service through our viewmodel and our viewmodel is not interested in what happens behind anymore. The service can do his work and only give back his results. But you have to correct you binding now because your number is not in the viewmodel anymore but in the service behind.
We are now bind on our service “.” our property. Its the same with Commands. Commands should be seperate classes (in a seperated namespace) and you be offered through the viewmodel.
If you do this your viewmodel gets a complete facade and you can change the services underneath without touching the viewmodel. So every testcase you write for the viewmodel would be untouched :)
Note: Your viewmodel does not have to implement INotifypropertyChanged then. If you make classes/interfaces which are providing informations to the UI these classes are the only ones who have to implement INotifyPropertyChanged.
If you think further it would be better to seperate the service one again and getting a provider between the service, which is doing the real job and the class/interface, which is giving the data to the outside world. This provider (or however you call it) can then be offered in the viewmodel and you would bind first over this one. But for now this should be it, I think you got my point ;) .