MVVM pattern for WPF: Model vs ViewModel

Question

I can't really wrap my head around the following problem:

All I have in the application is a textboxfor the user input, a button for performing a background calculation on that input and a textblock. Imagine I have to use MVVM, so I have my view, viewmodel and model classes.

I bind the controls (textbox, button and textblock) from the view to the viewmodel on corresponding properties and commands. However, I'm not sure where the viewmodel functionality should end. For instance, would the following be a way to structure the application?

Model:

public class Model
{

    public string Input { get; set; }
    public string Output { get; set; }

    public void FancyMethod ()
    {
       // Use input to calculate output
    }

}

ViewModel:

public class ViewModel
{

    public string Input {get; set;}
    public string Output {get; set;}
    public ICommand command {get; set;}
    public Model model {get; set;}

    public ViewModel() 
    {
      model = new Model();
    }

    // When the button is pressed, model.input = Input and then execute model.FancyMethod()

}

Maybe this post will help you: https://stackoverflow.com/questions/23648832/viewmodels-in-mvc-mvvm-seperation-of-layers-best-practices#23649191 — Stefan, Jul 16 '18 at 13:03
Model is the representation of your database table, so your `FancyMethod` needs to be out of your model class. Move it to your ViewModel class, and call it when you click the button or what ever operation/event you want. — sharp, Jul 16 '18 at 13:08
It calculates the value from input and then assigns the calculated value to output — karolyzz, Jul 16 '18 at 13:39

Stefan · Accepted Answer · 2018-07-17T07:55:02.377

If you want to keep a clean layer model, you should not include public Model model {get; set;} in your ViewModel.

So, for example, if you have a command, targeting some business model, your structure should be something like this:

//you don't have this one... but well, maybe other cases have
public class SomeService : ISomeService
{
    //member of ISomeService
    public void SomeFancyMethod(Model model)
    {
        //do stuff..
    }
}

public class Model //might be database, or domain model.
{
   public string Input { get; set; }
   public string Output { get; set; }
}

As for your viewmodel, it will become something like this:

public class ViewModel
{
    private ISomeService _someService;

    //note: someService is passed through a IoC service like ninject, unity, autofac etc.
    public ViewModel(ISomeService someService)
    {
        _someService = someService;
        //initialize the command:
        command = new RelayCommand(() =>
        {    
            _someService .SomeFancyMethod(new Model()
            {
                //properties could be mapped with an automapper.
            });
        });
    }

    public ICommand command {get; private set;}
    public string Input {get; set;}
    public string Output {get; set;}
 }

Note: there are some additional techniques involved:

using an inversion of control container, and pass the service through the constructor.
abstracting the service by means of an interface (ISomeService)
possibly some automapper to isolate your mapping from and towards Models/ViewModels

"So why make this so 'complicated'? You are just making a copy.", a commonly heard argument against this pattern:

Well:

it isn't complicated
doing this will separate your layers. This mean that changes in your datalayer doesn't break your View. In the long run, you'll benefit, as change will come and you'll need to maintain the code.

Note that a new `RelayCommand` instance is created every time the getter is accessed when it could just be a private field (readlonly or created once on first access). — blins, Jul 16 '18 at 13:24
Add then, once you get a bit further down the track, you inject SomeService into ViewModel using a dependency injection framework (i.e. Ninject). — Mark Feldman, Jul 16 '18 at 20:36

score 1 · Answer 2 · answered Jul 16 '18 at 13:43

I guess the FancyMethod() contains your business logic and produces a value that you want to display in the view. In this case, FancyMethod() belongs to your model as it contains some business logic that is the same regardless of whether it's being executed in the context of a client application or some other component.

So your model would look something like this, i.e. it accepts an input and produces an output but it doesn't expose any properties that a view may bind to:

public class Model
{
    public string FancyMethod(string input)
    {
        // Use input to calculate output
    }
}

You could then inject your view model with the model and call the FancyMethod when the user executes the command by clicking on the Button in the view:

public class ViewModel
{
    private readonly Model _model;
    public ViewModel(Model model)
    {
        _model = model;
        command = new RelayCommand(Execute, CanExecute);
    }

    public string Input { get; set; }
    public string Output { get; set; }
    public ICommand command { get; private set; }

    private bool CanExecute(object _)
    {
        return !string.IsNullOrEmpty(Input);
    }
    private void Execute(object _)
    {
        Output = _model.FancyMethod(Input);
    }
}

Obviously the view model class should also implement the INotifyPropertyChanged interface and raise change notifications to the view.

In short the business logic belongs to the model and the application logic, for example what happens when a user clicks a Button, belongs to the view model.

score 0 · Answer 3 · answered Jul 16 '18 at 13:17

I think its not necessary to outsorce the Input and Output properties in another class. The reason for this is that the properties reflect the input and output of the view. So they have to be in the viewmodel. You can outsorce the SomeFancyMethod in a service class to separate the logic from the viewmodel anlogous to mvc.

MVVM pattern for WPF: Model vs ViewModel

3 Answers3