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 :

1. 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 ?
2. For the WCF data transport, should I have relational
   properties in my model, i.e a Product has a Customer instead of a
   CustomerId ?
3. 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…

Answer 1

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.