Problems understanding use of MVVM when using WCF DTO's in a WPF smart client app

Here is my thinking about your questions:

Question: Would the recommended approach be to convert these DTOs to a model which implemented INotifyPropertyChanged using Automapper or similar? Or should the DTO be used as the model directly in the viewmodel?

Answer: My approach I like the most is containment. I agree with you DTO shouldn't have anything but getters and setters. Keep it as clean as possible, hence it shouldn't fire INotifyPropertyChanged. I also don't think the View should have direct access to object model (if for no other reason, you don't have the benefit of property changed). The disadvantage of my approach is some extra code in the ViewModel, but I think it worth it.

public class VmBase : INotifyPropertyChanged {    public event PropertyChangedEventHandler PropertyChanged;    protected virtual void raise( string propName )    {        if( PropertyChanged ) {            PropertyChanged( this, new PropertyChangedEventArgs(propName) );        }    }}public class OrderLineVm : VmBase {    private OrderLineDTO orderLine;    public OrderLineVm( OrderLineDTO ol ) {        orderLine = ol;    }    public OrderLineVm( ) {        orderLine = new OrderLineDTO();    }    int customerId {        get { return orderLine.customerId; }        set { orderLine.customerId=value; raise("customerId"); }    }    int productId {        get { return orderLine.productId; }        set { orderLine.productId=value; raise("productId"); }    }    double quantity {       ...    }}

Through the miracle of garbage collection, the OrderLineDTO will be created only once (when it comes from the server) and live as long as it is needed. There are two public constructors: one with the DTO (typically, when objects coming from the server), and one created on the client.

For the OrderVm this is a little bit more complex, since you would like to have a ObservableCollection (vs. List) of OrderLineVm (vs. OrderLineDTO), so containment won't work. Also note that orderLines only has a getter (you add and remove order lines from it, but you don't change the entire list. Allocate it once during construction).

public class OrderVm : VmBase {    private string _orderDetails;    public string orderDetails {        get { return _orderDetails;        set { _orderDetails=value; raise("orderDetails"); }    }    private ObservableCollection<OrderLineVm> _orderLines;    public ObservableCollection<OrderLineVm> orderLines {         get { return _orderLines; }    }}

Question: How would the OrderViewModel communicate to the OrderLineViewModel in this scenario?

Answer: If a communication is required, indeed you should do it the simplest way. Both View Model classes are at the same layers. The OrderVm references a list of OrderLineVm, and if you need a communication from OrderLineVm class to order, just keep a reference.

However, I would strongly argue that a communication isn't needed. Once the View is bound appropriately, I see no reason for such communication. The Mode property of the binding should be "two way", so everything changed in the UI will be changed in the View Model. Addition, Deletion to the list of order lines will reflect automatically on the View thanks to the notifications sent from the ObservableCollection.

Questions: Do you allow the user to add an invalid line send the request to the server let the server apply the relevant rules and return the response? Or do you somehow apply the logic in the smart client app before sending the request to the server?

Answer: There is nothing wrong having data validation on the client, in addition to the server. Avoid duplicate code - have a single assembly (probably the assembly that defines the DTO) that performs the validation, and deploy this assembly in the client. This way your application will be more responsive, and you will reduce workload on the server.

Obviously you need to do data validation on the server (for security reason, and for race conflicts). You must handle situation when the server returns errors even though validation on the client passed.

EDIT: (follow up on comment from Alex):

Showing a dropdown list: I think the source of your confusion is that there are actually two independent ItemsSource (and hence two separate data context): There is one list of order lines, and embedded within each order line is the list of ProductIDs, which are the items populated the combobox. It is only the SelectedItem that is a property of the ProductLine. Typically, the list of possible ProductID should be global to the application (or the order). You'll have the ProductIDs a property of the entire form, and give it a name (e.g. x:Key or x:Name). Then, in the ComboBox element just reference this list:

<ComboBox ItemsSource="{Binding Source={StaticResource ProductIDs}}"          SelectedItem="{Binding Path=productId}"          />

To answer your questions in turn ...

1) If you do not need your properties to notify the UI when they change, then there is no need to use INotifyPropertyChanged - and in my opinion you can bind the Model directly to the View. There is no need to add an extra layer if it does not add any extra functionality. However, in most applications you will want to change model object state via the UI. In this case, you will need to add View Model objects that implement INotifyPropertyChanged. You can either make a view model that adapts the model, i.e. delegating properties to the underlying model, or copy the model object state to an equivalent view model.

In order to avoid writing lots of rather similar code, i.e. the same domain object represented as a model object and view model object, I try to use code-generation where possible. I like using XML to describe my model, and T4 templates for codegen.

2) How should OrderViewModel communicate to the OrderLineViewModel? directly! The concepts sound quite closely coupled, I would guess that an order has multiple order lines? In this case just have each view model reference the other. No need for fancy mediators if the two are closely coupled within your domain.

3) Good question! I agree that the server should apply validation. Whether you duplicate some of this validation in the client depends on your requirements. If your communication with the server is fast and frequent, you might be able to provide a good user experience by communicating with the server as the user edits the orders and providing validation as they proceed from field to field. However, in many cases this is not practical. It is quite common to apply simple validation within the client application, but allow the server to do the more complex checks, for example checking for uniqueness etc...

Hope that helps.

I have 2 years of experience with building "rich clients" (in WPF).

In my WPF smart client I then have a reference to the DTO but clearly it does not implement INotifyPropertyChanged as it is purely for transport.

Wrong
WCF will automatically implement INPC on every DTO, by default.
Best would be to use the DTOs as ViewModels for simple views, and for more complex views, use the composition "pattern".

Communicating between view models

The "best" practice (read: what pretty much everybody does) is to use a weak event pattern, to keep things loosely coupled. The most renowned one being IEventAggregator from the PRISM library, but there are several implementations out there.

Adding an order line and applying logic / business rules

Think of the client the same as a webpage: do not trust it. It is .NET code, and we all know how easy it is to hack into.
Which is why, you should have the security checks implemented on your WCF service.

HTH,

Bab.