Wie würde ich wissen, ob ich Self-Tracking-Entitäten oder DTOs / POCOs verwenden sollte?

Wenn ich Ihre Architektur verstehe, ist es meiner Meinung nach nicht gut für STEs weil:

• Modelle werden sowohl auf der Clientseite als auch auf der Serverseite zur Validierung verwendet. Wir wären nicht direkt an den DTO oder STE
gebunden

Der Hauptvorteil (und der einzige Vorteil) oder STEs ist ihre Tracking-Fähigkeit, aber die Tracking-Fähigkeit funktioniert nur, wenn STE auf beiden Seiten verwendet wird:

• Der Client-Abfrageserver für Daten
• Der Server fragt EF ab und empfängt eine Menge von STEs und gibt sie an den Client zurück
• Der Client arbeitet mit STEs, modifiziert sie und sendet sie zurück an den Server
• Der Server empfängt STEs und wendet die übertragenen Änderungen auf EF = & gt; Datenbank

Kurz gesagt: Es gibt keine zusätzlichen Modelle auf Client- oder Serverseite. Um STEs vollständig zu nutzen, müssen sie:

• Serverseitiges Modell (= kein separates Modell)
• Übertragene Daten in WCF (= keine DTOs)
• Client-seitiges Modell (= kein separates Modell, das direkt an STEs gebunden ist). Andernfalls duplizieren Sie Tracking-Logik, wenn Sie Änderungsereignisse an begrenzten Objekten bearbeiten und STEs ändern. (Der Client und der Server teilen die Baugruppe mit STEs.)

Jedes andere Szenario bedeutet einfach, dass Sie die Vorteile der Self-Tracking-Fähigkeit nicht nutzen und Sie sie nicht benötigen.

Was ist mit Ihren anderen Anforderungen?

• Benutzer können ihre eigene Schnittstelle definieren, sodass sich die vom WCF-Dienst benötigten Daten ändern, je nachdem, welche Schnittstelle der Benutzer für sie definiert hat.

Dies sollte wahrscheinlich möglich sein, aber stellen Sie sicher, dass jeder "Lazy Loaded" -Teil eine separate Struktur ist - erstellen Sie kein komplexes Modell auf der Client-Seite. Ich habe schon Fragen gesehen, bei denen Leute ganze Entity-Graphen für Updates zurücksenden mussten, was nicht das ist, was Sie immer wollen. Aus diesem Grund sollten Sie keine geladenen Teile in ein einzelnes Objektdiagramm einfügen.

• Auf der Serverseite gibt es Berechtigungsprüfungen, die sich darauf auswirken, wie die Daten zurückgegeben werden. Zum Beispiel sind einige Daten entweder teilweise oder vollständig maskiert, basierend auf der Rolle des Benutzers

Ich bin mir nicht sicher, wie du das wirklich erreichen willst. STEs verwenden keine Projektionen, daher müssen Sie Felder direkt in Entitäten löschen. Beachten Sie, dass Sie dies tun müssen, wenn sich die Entität nicht im Tracking-Status befindet oder Ihre Maskierung in der Datenbank gespeichert wird.

• Die Datenbankschicht spammt mehrere Server / Datenbanken

Es ist etwas, das kein Problem von STEs ist. Der Server muss einen korrekten EF-Kontext verwenden, um Daten zu laden und zu speichern.

STEs sind eine Implementierung von Änderungssatzmustern. Wenn Sie sie verwenden möchten, sollten Sie ihre Regeln befolgen, um das Muster voll auszunutzen. Sie können etwas Zeit sparen, wenn sie richtig verwendet werden, aber diese Beschleunigung kommt mit dem Verzicht auf einige architektonische Entscheidungen. Wie bei jeder anderen Technologie sind sie nicht perfekt und manchmal sind sie schwer zu benutzen (folgen Sie einfach Self-Tracking-Entities <) / a> tag, um Fragen zu sehen). Sie haben auch einige schwerwiegende Nachteile , aber in .NET WPF-Client Du wirst sie nicht treffen.

Sie können STE für das gegebene Szenario wählen,

• Alle STEs sind POCOs, .Net fügt dynamisch eine Ebene hinzu, um Änderungen zu verfolgen.
• Verwenden Sie T4-Vorlagen, um die STEs zu generieren, das spart Zeit.
• Die Verwendung von Tools wie Automapper speichert Ihre Zeit für die manuelle Konvertierung von WCF-Datenkontrakten in Entity oder DTO

Vorteile für STE -

1. Sie müssen die Änderungen nicht manuell verfolgen.
2. Im Falle von WCF müssen Sie nur applydbchanges sagen und es wird automatisch die Entity
aktualisieren

Nachteile für STE -

1. STEs sind schwerer als POCO wegen der dynamischen Verfolgung

Vorteile für POCO -

1. Geringes Gewicht
2. Kann leicht mit EF oder nH
überbrückt werden

Nachteile für POCO -

1. Sie müssen die Änderungen manuell mit EF verfolgen. (schmerzhaft)

POCO sind dynamisch proxied und spielen nicht nett auf dem Draht sehen diesen MSDN Artikel für die Problemumgehung obwohl . Sie können also gemacht werden, aber IMO geht es besser los mit STE, da ich glaube, dass sie sich gut mit der WPF / MVVM-Entwicklung decken.