WPF MVVM WCF client/server architecture

Question

I want to build a basic wpf/mvvm application which gets the data from a server with WCF and allows the client to display/manipulate (with CRUD operations) this data.

So far, I thought about something like that for the architecture :

a "global" model layer, which implements validation, research criterias, and INotifyPropertyChanged and services contracts
some services layers, by mainly one for entity framework 4, implementing the contracts of the model layer and allowing me to access and manipulate data.
Note that I want to have an offline datasource as well, say XML or something else, and thus another service (I plan on using some DI/IoC)
the WCF layer
Extra layer for data storing client side ?
the ViewModel

I'm clear on the Views/ViewModel part, but I have troubles figuring out the relations between the model, WCF and the viewmodel.

My questions are :

How should I handle the model generated by EF ? Get rid of it and go for a code first approach, manually doing the mapping with the database ?
For the WCF data transport, should I have relational properties in my model, i.e a Product has a Customer instead of a CustomerId ?
Should I have an additional layer between the WCF and the ViewModel, for storing and manipulating data or is it a best practice to directly plug the ViewModel into the WCF ?

Any other tips for this kind of architecture are welcome...

You might want to read my answer to stackoverflow.com/q/10437241/50079 — Jon
@Jon : your answer is great indeed, thanks. However I'm not yet perfectly clear on the Model part, cf. my answer to ken2k — LaurentH

ken2k ken2k · Accepted Answer · 2012-07-11T12:54:42

There are different solutions for the architecture of a 3-tier WPF application, but here is one possibility:

1+2) One solution is to create "intermediate" objects that represent what your client application actually needs. For instance, if your application needs to display information about a product plus the associated customer name, you could build the following object:

public MyProduct
{
    // Properties of the product itself
    public int ProductID { get; set; }
    public string ProductName { get; set; }
    ...

    // Properties that come from the Customer entity
    public string CustomerName { get; set; }
}

You can then expose a stateless WCF service that returns your product from an ID:

[ServiceContract]
MyProduct GetProductByID(int productID);

In the server side of your application (i.e. the implementation of your service), you can return a MyProduct instance build by querying the database through EF (one context per call):

public MyProduct GetProductByID(int productID)
{
    using (DBContext ctx = new ....)
    {
        return from p in ctx.Products
            where p.ID == productID
            select new MyProduct
            {
                ProductID = p.ID,
                ProductName = p.Name,
                CustomerName = p.Customer.Name  // Inner join here
            };
    }
}

3) Adding additional layer between the WCF services and the ViewModel might be considered as over-engineering. IMHO it's OK to call WCF services directly from the ViewModel. WCF generated client proxy code has the actual role of your model (at least one part of your model).

EDIT:

why MyProduct should reference the CustomerName instead of the Customer.In my case, Customer would have many properties I'd work with. Woudn't this "mapping" be too expensive ?

You can use the actual entities. But on client side, as it's a 3-tier architecture, you have no access to the DB through the navigation properties. If there was a nested Customer property (of type Customer), the client would have access to theProduct.Customer.Products, which has no sense has you can't lazy load entities this way (no DB context on client side).

Flattened "intermediate" POCOs are much more simple IMO. There is no performance issues, the mapping is straightforward and the CPU usage for this particular operation is infinitesimal compared to the DB request time.

WPF MVVM WCF client/server architecture

2 Answers