WCF Services in WPF App – Learning to Use with MVVM

mvvmwpf

We're working on a major re-write of a legacy VB6 app, into a WPF app. I've written several WCF services, which are meant to be used with the new WPF app. We want to use the MVVM design pattern to do this, but we don't have experience at that. So, in order to learn MVVM we've watched a video on WindowsClient called How Do I: Build Data-driven WPF Application using the MVVM pattern. This is a great introduction, and we refer to it a lot, but for our situation it doesn't quite give us enough. For example, we're not certain how to use datasets returned by my WCF services in our new WPF app using the ideas that Todd Miranda introduced in the video I referenced. If we did as we think we're supposed to do, then we should design a class that is exactly like the class of data returned in my WCF service. But we're wondering, why do that, when the WCF service already has such a class? And yet, the class in the WPF app has to at least implement the INotifyPropertyChanged interface. So, we're not sure what to do.

Best Answer

WCF's data objects should ideally be light-weight data transfer objects only. I would only re-use WCF's data objects if:

My Models are always going to be simple POCO objects. No validation, no business logic, no property change notification, etc
I don't care that the entire class as visible and fully accessible to whoever used it (You can't have read-only properties in a WCF data model)
My View does not bind directly to the Model, and instead binds to ViewModel properties which expose Model properties. This is the "MVVM-purist" approach, however if it often more trouble to implement than it is worth, so binding your View to your Model is also acceptable

That being said, I have never actually used WCF data objects as my Models. Usually I create Model objects separately, and my client-side data access layer converts the WCF data objects into Models for my application to use.

I usually use something Automapper for this, which will automatically map data from one class to another, providing the names and types are the same.

Related Solutions

C# – How to make creating viewmodels at runtime less painful

The issue of dependencies when initiating a new view model can be handled with IOC.

public class MyCustomViewModel{
  private readonly IShoppingCartWebService _cartService;

  private readonly ITimeService _timeService;

  public ProductDTO ProductDTO { get; set; }

  public ProductDetailsViewModel(IShoppingCartWebService cartService, ITimeService timeService){
    _cartService = cartService;
    _timeService = timeService;
  }
}

When setting up the container...

Container.Register<IShoppingCartWebService,ShoppingCartWebSerivce>().As.Singleton();
Container.Register<ITimeService,TimeService>().As.Singleton();
Container.Register<ProductDetailsViewModel>();

When you need your view model:

var viewmodel = Container.Resolve<ProductDetailsViewModel>();
viewmodel.ProductDTO = myProductDTO;

When utilizing a framework such as caliburn micro there is often some form of IOC container already present.

SomeCompositionView view = new SomeCompositionView();
ISomeCompositionViewModel viewModel = IoC.Get<ISomeCompositionViewModel>();
ViewModelBinder.Bind(viewModel, view, null);

MVVM Architecture – Clarification and Explanation

In general, I would not place business logic in the view model layer. But the term "Business Logic" is misleading.

Eric Evans uses a model where business logic is divided into two categories

Domain logic - Logic related to the actual problem domain you are solving
Application logic - Logic related to the fact, that you are building an application

He mentions the example of an accounting application. Rules about accounts, posts, tax accounts, etc. are domain rules, rules pertaining to the domain of accounting. Logic about CSV import/export has nothing to do with the domain of accounting. These rules exists purely because we are building a software application. These are examples of application logic.

Domain rules should NEVER go into the view model layer. If you are following the MVVM pattern, then the domain rules go, without question, in the model layer.

Application rules, like CSV import/export, could go in the view model layer. But personally, I would prefer to separate that out into a separate application logic layer.

The View Model should be very simple. Looking up the data needed by the view in the corresponding model, updating the model when the view changes, listening to events in the model, and propagating those events to the view, allowing the view to be updated when the model is updated behind the scenes (if applicable).

Personally I would make sure that the view model layer contains only one type of logic, presentation logic.

Best Answer

Related Solutions

C# – How to make creating viewmodels at runtime less painful

MVVM Architecture – Clarification and Explanation

Related Topic