C# MVVM Where Does the Service Layer Sit?

Question

I am attempting to develop a little program which will communicate with a device on a serial port. The program will be responsible for formatting user entered data and reading and presenting values received by the device. I am pretty new to WPF and MVVM and have achieved a basic understanding of the whole databinding / XAML mess (I think).

Currently my understanding goes something like:

1. View: UI only stuff. Binds to ViewModel.
2. ViewModel: Takes a model or various properties of a model and presents them in a way that the View can understand. Also provides a way for the view to modify the model.
3. Model: The data the UI presents and modifies.

Now I am at a loss as to what provides Models to the ViewModel such that the application as a whole is aware of changes to Models.

The Model currently looks something like the following. My device takes calibration records and can read back all the calibration records.

public class Device : ObservableObject
{
    public ObservableCollection<CalibRecord> CalibRecords { get; set; }

    private SerialPort sp;

    public Device(SerialPort port)
    {
        this.sp = port;
        this.CalibRecords = new ObservableCollection<CalibRecord>();
    }

    public void WriteCalibration(CalibRecord record)
    {
        /* Write a calibration record to the device */
    }

    public void ReadCalibration()
    {
        /* Read all calibration records from the device and update CalibRecords */
    }
}

I am struggling for a place to put this guy so that it can be accessed by the entire application. Currently I instantiated it in the main window's ViewModel but then it can't be accessed by other ViewModels unless I inject it into the constructor. This is fine for a couple classes but gets unwieldy quickly the more classes a ViewModel needs.

Perhaps this is what the so-called "business logic" or "service layer" is. Can you help me understand where to put the business logic in an MVVM app? Or, do you guys have some examples I should look at that focuses on the whole application (particularly the business logic) and not just the MVVM stuff?

Answer 1

Your understanding of MVVM is correct, but the "textbook description" doesn't account for services. Typically this is done with dependency injection (DI). Define an interface, IMyDevice and implement it in a MyDevice class. Then register it with your DI container IMyDevice -> MyDevice. By using a DI container (properly) you'll also take yourself out of the VM construction picture. You would have a VM something like:

public class MyViewModel : ViewModelBase
{
  public MyViewModel(IMyDevice myDevice)
  {
  }
}

to get an instance of the VM, you would do:

theDIContainer.Resolve<MyViewModel>();

and it would new up the MyViewModel class and automatically resolve and pass in the IMyDevice instance for you.

There is a lot more to DI then I covered here... just a basic 10,000 mile high answer to your question. Read up on DI and see how it comes into play with MVVM.

Answer 2

The mindset of MVVM is to separate in a loosely coupled manner layers, allowing each to be modified and tested without interfering with the other.

You test the ViewModel and mock the Models. You test the Models. Your Model may take form of several services automatically injected by some DI container. Subsequently there is as little as possible friction between the Models, the ViewModel. Eventually they may be deployed independently; this lowers maintenance and cost; that's the same mindset of that of microservices.

For instance, you might have a Model that is tested and can be used for a WPF app, mobile app, web app, etc. Your ViewModel however should not a priori be involved in another GUI. You can update your webapp without commit/deploy for the other and the Model; lower cost, lower duration commit-to-deploy (including testing).

When you start with cohesive classes and test them, it will be clear where to put what.

It's OK to have only a View and a ViewModel; though the Model should have the business logic if it's enough rich; you should have tests for the Model, tests for the ViewModel ( behavior of the UI). The VM and the Model layers can be much more complicated than just 2 classes, you may have multiple (automatic) dependency injections (check the excellent Dependency Injection in .NET, Mark Seemann).

Subsequently, logic (for your business) should go in the Model, not in the ViewModel; logic for the UI should go in the VM.

Regarding WPF, the View take the form of a UserControl with View.xaml (what you see) and View.xaml.cs (the code-behind); not all UI logic goes into the ViewModel; pure View logic goes into the code-behind. The code-behind contains in particular all the dependency properties, behavior logic (shared with the xaml code) etc.