WPF MVVM WCF client/server-Architektur

Gibt es verschiedene Lösungen für die Architektur einer 3-tier-WPF-Anwendung, aber hier ist eine Möglichkeit:

1+2) Eine Lösung ist die Schaffung von "intermediate" - Objekte, die darstellen, was Ihre client-Anwendung tatsächlich benötigt werden.
Zum Beispiel, wenn Ihre Anwendung zum anzeigen von Informationen über ein Produkt sowie der dazugehörigen Kunden-Namen, die man bauen konnte das folgende Objekt:

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; }
}

Können Sie dann über eine stateless-WCF-service, gibt Ihr Produkt aus einer ID:

[ServiceContract]
MyProduct GetProductByID(int productID);

In die server-Seite der Anwendung (d.h. die Implementierung des service), können Sie die Rückgabe einem MyProduct - Instanz erstellen, indem Sie eine Abfrage der Datenbank durch EF (ein Kontext pro Anruf):

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) Hinzufügen einer zusätzlichen Schicht zwischen der WCF-Dienste und das ViewModel könnte betrachtet werden als over-engineering. IMHO ist es OK, um WCF-Dienste aufrufen, die direkt aus dem ViewModel. WCF generierten client-proxy-code, der die eigentliche Rolle des Modells (zumindest einen Teil Ihres Modells).

EDIT:

warum MyProduct sollte die Referenz der Kundenname statt der
Kunden.In meinem Fall, der Kunde hätte viele Eigenschaften, ich würde arbeiten
mit. Woudn nicht dieses "mapping" zu teuer ?

Können Sie die tatsächlichen Personen. Aber auf client-Seite, es ist eine 3-tier-Architektur, haben Sie keinen Zugriff auf die DB über die Navigations-Eigenschaften. Wenn es eine verschachtelte Customer - Eigenschaft (vom Typ Customer), der Kunde hätte Zugang zu theProduct.Customer.Products ist, hat kein Sinn hat Sie kann nicht lazy load entities auf diese Weise (keine DB-Kontext auf der client-Seite).

Abgeflacht "intermediate" POCOs sind viel einfacher IMO. Es gibt keine performance-Probleme, die Zuordnung ist unkompliziert und die CPU-Nutzung für diese bestimmte operation, ist verschwindend gering im Vergleich zu den DB-request-Zeit.