___ qstnhdr ___ Wie würde ich wissen, ob ich Self-Tracking-Entitäten oder DTOs / POCOs verwenden sollte?
___ qstntxt ___
Welche Fragen kann ich mir zu unserem Design stellen, um festzustellen, ob wir in unserer Anwendung DTOs oder Self-Tracking Entities verwenden sollten?
Hier sind einige Dinge, die ich beachten kann:
- Wir haben eine Standard-n-Tier-Anwendung mit einem WPF / MVVM-Client, einem WCF-Server und einer MS SQL-Datenbank.
- Benutzer können ihre eigene Schnittstelle definieren, sodass sich die vom WCF-Dienst benötigten Daten ändern, je nachdem, welche Schnittstelle der Benutzer selbst definiert hat
- 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
- Einige Modelle enthalten Eigenschaften, die bei Bedarf vom WCF-Dienst lazy-geladen werden
- Die Datenbankschicht spammt mehrere Server / Datenbanken
- 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
- Unsere Ressourcen sind begrenzt (Zeit, Arbeitskraft usw.)
Also, wie kann ich feststellen, was für uns richtig ist? Ich habe EF noch nie benutzt, daher weiß ich wirklich nicht, ob STEs für uns richtig sind oder nicht.
Ich habe gesehen, dass Leute vorschlagen, mit STEs zu beginnen und nur DTOs zu implementieren, wenn sie zu einem Problem werden, aber wir haben derzeit DTOs und versuchen zu entscheiden, ob die Verwendung von STEs das Leben einfacher machen würde. Wir sind früh genug in dem Prozess, dass Switching nicht zu lange dauern würde, aber ich möchte nicht zu STEs wechseln, nur um herauszufinden, dass es nicht für uns funktioniert und alles zurückschalten muss.
___ tag123entityframework4 ___ Ein Tag für ADO.NET Entity Framework 4.x, selbst eine objektrelationale Zuordnung für das .NET-Framework.
___ answer5463866 ___
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:
sein
- 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.
___ tag123wcf ___ Windows Communication Foundation ist ein Teil von .NET Framework, das ein einheitliches Programmiermodell für die schnelle Erstellung von serviceorientierten Anwendungen bereitstellt.
___ answer5437394 ___
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 -
- Sie müssen die Änderungen nicht manuell verfolgen.
- Im Falle von WCF müssen Sie nur applydbchanges sagen und es wird automatisch die Entity
aktualisieren
Nachteile für STE -
- STEs sind schwerer als POCO wegen der dynamischen Verfolgung
Vorteile für POCO -
- Geringes Gewicht
- Kann leicht mit EF oder nH
überbrückt werden
Nachteile für POCO -
- Sie müssen die Änderungen manuell mit EF verfolgen. (schmerzhaft)
___ tag123elftrackingendities ___ In einer Entity Framework-basierten Anwendung ist ein Kontext dafür verantwortlich, Änderungen an Ihren Objekten zu verfolgen. Self-Tracking Entities (STEs) können Ihnen helfen, Änderungen in jeder Schicht zu verfolgen und diese Änderungen dann in einem Kontext wiederzugeben, der gespeichert werden soll.
___ tag123nichtArchitektur ___ N-Tier-Architektur bezieht sich auf die Architektur einer Anwendung, die mindestens 3 "logische" Schichten oder separate Teile aufweist. Jede Ebene interagiert nur mit der Ebene direkt darunter und hat eine spezifische Funktion, für die sie verantwortlich ist.
___ tag123poco ___ Bedeutet einfaches altes CLR-Objekt, ein einfaches Objekt, das keinem Objektmodell, keiner Konvention oder keinem Framework folgt. Bei Fragen zur POCO C ++ - Bibliothek (http://pocoproject.org) verwenden Sie bitte [poco-libraries].
___ answer5463204 ___
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.
___