Someone told me in an answer to a stackoverflow question that the "two big guns" for the MVVM pattern are 1) attached behaviors and 2) services. I assume he means "WPF services" a phrase which I found used in the following ways:
PresentationFoundation.dll defines the WPF controls types, animation and multimedia support, data binding support, and other WPF services.
Many of these WPF services ( de-coupled eventing, rich databinding, styling, resources, etc.) are software development best practices that converge in a single, declarative UI stack.
You will understand the motivation behind WPF, learn the syntax of XAML, examine the core programming model, and survey several WPF services.
None of the WPF books I have even mention "WPF services" as such, so is this just a word that means "WPF features" such as decoupled eventing, rich databinding, styling, etc. or is there something else behind the term "WPF Services"?
Martin Fowler has a description of what a service is in his Dependency Injection article. Put simply, a service is an object that provides functionality to be used by other objects. You'll find the term used heavily when discussing the patterns Inversion of Control and Service Locator.
To make this concrete with the topic at hand, let's think about how we'd display a message box in the MVVM pattern. Calling MessageBox.Show() would be bad, Ray. This ties the ViewModel tightly to the UI architecture, and makes the ViewModel difficult to test. Instead, one solution would be to use a service, which we'll call IDisplayMessage. This service is supplied to the ViewModel somehow (through one of the two patterns above), and this service is used to "display" a message. During normal operation, a concrete version of this service will call MessageBox.Show(), but during testing we can provide a different concrete version (a test double) that behaves differently (a noop often, or if we're ensuring the ViewModel displays the message, a version that records the call so we can assert that it occurred). Onyx (disclaimer: I'm the author) provides just such a service, and the infrastructure necessary for providing this service (and others) to your ViewModel.
Update: Since this response was made, I've written a blog post Services: Your ViewModel Deathstar, which covers the topic fairly well. This was part of a "series" of posts, and readers may also be interested in the first post Behavior - Your Trusty ViewModel Bazooka.
He's not talking about WPF services, but application services. That is, abstracting some portion of functionality into an independent service that multiple VMs can consume.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With