can I use WCF interface as a MVVM Model?

问题:

My WPF application should receive data from pipe via WCF: I'm new to MVVM and I can't understand where to put some stuff. It's clear for me what is View but it not clear what is ViewModel and especially what is Model in my case (in case when WCF involved) The questions are:

• what is Model? Do I need special class to represent model? Or Model is WCF server application? What is valid worflow "WCF Server application ----named pipe-----> ViewModel <--Data binding--> View" or "WCF Server application ----named pipe-----> Model<--->ViewModel <--Data binding--> View"

• how to refactor code below? where to put all this initialization? to ViewModel? to Model class (if I need it), to special "initialization" class?

  public MainWindow()
  {
  ChannelFactory<IManagementConsole> pipeFactory =
  new ChannelFactory<IManagementConsole>(
      new NetNamedPipeBinding(),
      new EndpointAddress(
          "net.pipe://localhost/PipeMBClientManagementConsole"));
  
      IManagementConsole pipeProxy =
        pipeFactory.CreateChannel();
  
      List<ConsoleData> datas = new List<ConsoleData>();
      foreach (StrategyDescriptor sd in pipeProxy.GetStrategies())
      {
          datas.Add(pipeProxy.GetData(sd.Id));
      }
      this.DataContext = datas;
  }
  

Can I assume that this is my MVVM Model? :

[ServiceContract]
public interface IManagementConsole
{
    [OperationContract]
    ConsoleData GetData(int strategyId);

    [OperationContract]
    List<StrategyDescriptor> GetStrategies();
}

回答1:

A Model is a class that describes data from backend data source. They can be the actual classes from the source (like EF or WCF Proxies) or they can be simple DTOs. It really depends on your preference.

A ViewModel is a class that describes data for display in the View. Frequently, but not necessarily, the data comes from Model classes.

The ViewModel is responsible for managing the Model classes: exposing their information to the View and doing something with/to them based on input from the View. That being said, I prefer not to see the actual communications work in the ViewModel. Instead, I abstract the communications into another layer (I call mine the Service layer, but that can be confusing in this context).

In essence, I have the ViewModel make requests to the Service layer which communicates with the backend to retrieve/create Model objects that are then returned to the ViewModel. This gets complicated if the service calls are Asynchronous but can still be done.

For a simple example of this, download the code sample from practicalmvvm.com.

回答2:

Can I assume that this [IManagementConsole] is my MVVM Model? :

Yes it is (can be) the Model. But it's very unlikely it is usable as the ViewModel.

A ViewModel 'wraps' the Model and makes it suitable to support the UI-content and UI-logic.

In your case you'll want a class ManagementConsoleViewModel and a class StrategyDescriptorViewModel.

The ViewModels implement INotifyPropertyChanged and may provide Commands and extra properties for databinding.

Best thing is to look into some basic MVVM samples (it's really very basic, just add BaseViewModel and RelayCommand classes to your project) and then decide on a (small) Framework. Like Caliburn-micro or MVVM-light.

回答3:

You could use your WCF service client as the MVVM "Model". However often an actual Model class is made that then uses the WCF services, since often times there isn't a single WCF service for a single View and/or ViewModel.

For example:

public class MyModel
{
    IUsersService usersSrv;
    ICompaniesService compSrv;

    public MyModel(IUsersService usersSrv, ICompaniesService compSrv)
    {
        this.usersSrv = usersSrv;
        this.compSrv = compSrv;
    }

    public string GetUserAndCompanyName()
    {
        return usersSrv.GetUserName() + " belongs to " + compSrv.GetCompanyName();
    }
}

In other words, your Model will typically contain the members that correspond with your View, whereas your WCF services will usually contain members that logically go together.