Entity Framework und DTO

Im planen, verwenden Sie die Entitäten generiert, indem die EF (POCO) in senden von Daten an den client anstatt DTOs? Ist das eine gute Praxis? Im Grunde, meine EDMX-Datei ist auf meiner DAL-layer.
Also der Benutzeroberfläche haben Sie direkten Zugriff auf mein DAL. Danke.

InformationsquelleAutor dotnetlinc | 2011-05-06
  1. 10

    Grundsätzlich, ich glaube nicht, dass es eine gute Idee, Sie zu senden DAL Objekte auf Ihrer Oberfläche, so würde ich die Verwendung von DTOs. Um den Aufwand zu minimieren tun, so würde ich einen Blick auf eine DTO-generator, zu generieren DTO code, ermöglicht die Konvertierung von DAL Objekt DTO und Umgekehrt.

    EDIT: Sorry, wollte nicht sehen, Sie sind mit POCO. Haben Sie einen Blick auf diese SO ein post

    • +1. Aber ich würde AutoMapper statt.
    • ja, ich bin mit automapper siehe meine Vorherige Frage stackoverflow.com/questions/5908237/casting-mapping-delegates ... es ist im Zusammenhang mit dieser Frage, ich habe ein problem bei der Verwendung DTO konvertieren Ausdruck<U<DTO.Person,bool> zum Ausdruck<U<Kontext.Person,bool> das ist, warum ich bin versucht, vollständig zu beseitigen DTOs...
    InformationsquelleAutor dhoelzgen
  2. 11

    Es hängt davon ab, wie nah der Kunde ist an Ihrem Objekt-Domäne. Wenn es Ihre Kunden, dann vielleicht - und in der Tat, das ist ziemlich viel, wie ADO.NET Data Services (etc) arbeiten - direkt Sie Ihr Modell.

    Jedoch, wenn der AUFTRAGGEBER ist alles andere ich würde vorschlagen, eine dedizierte DTO. In der Tat, würde ich vorschlagen, dass es trotzdem ;p Ansonsten wird es etwas Komplex:

    • Steuerung der Serialisierung details (was für Mitglieder? was Namen? was passiert, wenn wir die version?)
    • handling-Eigenschaften Bezug (es hat eine Orders Mitglied... aber ist das träge geladen? möchten wir das?)
    • Zusammenführen der eingehenden Objekte (updates etc) wieder in das Modell
    • Ausblendung jeglicher Logik, die Sie Hinzugefügt haben, in der setter, etc, während der Deserialisierung
    • Umgang mit identity-management-wenn Sie 2 separate Kopien des gleichen Objekts wieder in einem Baum-basierten Serialisierung wie DataContractSerializer

    In den meisten Fällen, mit einem separaten DTO macht die meisten dieser Probleme nur Weg gehen

    • macht es Sinn, dass ich ' ll benutzen Sie einfach das DTO im Prozess, muss die Serialisierung wie WCF und einfach Daten abrufen wie die Bindung an raster verwende ich das EF-s stellen?
    • Sie meinen, wenn die EF entity Kunde hat Aufträge, es wird geladen, auch wenn ich nicht wirklich brauchen, die Aufträge? Ich dachte, es wird nicht geladen, bis Sie den Kunden anrufen.Aufträge.Load() ?
    • für die lokale uesage, die EF-Objekte sind in der Regel in Ordnung - in der Tat ich war die Fokussierung auf WCF (etc) Verwendung. Re Aufträge Frage: ich meine, es ist vor allem zu entfernen, dass Problem ganz, zusammen mit Komplikationen, was Sie mit eingehenden Daten mit Bestellungen. Durch das saubere Trennung zwischen DTO und domain-Objekt, kann man viel klarer code, mit weit weniger Bärenfallen, die aus Unklarheit über eingehende/ausgehende Daten (DTO), und der tatsächlichen vertrauenswürdigen Daten (domain-Modell)
    • Dank Mark! Ich denke, Krank versuchen diesem Ansatz in eine einfache Bindung ill die Verwendung der Domain.Kunde(EFs-entity), und dann, wenn ich expose/serialize entity gerade krank erstellen Sie einfach eine DTO.Kunden... =)
    InformationsquelleAutor Marc Gravell
  3. 1

    Zunächst, glaube ich, dass Sie nicht verwenden können Entitäten erzeugt, die von Entity Framework als zurückkehren Typen im Dienst, zumindest in einem WCF-Dienst.

    Aber, warum Sie verwenden möchten, um Entitäten über Ihre Anwendung? Wenn Sie haben eine gemeinsame Architektur eine client-server-Struktur, Ihre AUFTRAGGEBER müssen nicht alle Informationen, die ein EntityObject hat, wie der ObjectContext, wo es enthalten ist, der Staat, und viele andere info, dass Ihr Kunde nicht nur nicht verwenden, aber wichtiger noch: nicht zu wissen,.

    In diesem Fall sollten Sie das DTO-pattern, oder anderen design-Muster, die Sie denken besser entkoppelt die Server-Seite der Client-Seite. Ich glaube DTO-Pattern ist die am häufigsten verwendet und empfohlen.
    Wenn Sie mithilfe von Entity Framework können Sie gehen, um http://entitiestodtos.codeplex.com , es ist und AddIn für Visual Studio, die ich veröffentlicht, es ist kostenlos und open source. Es generiert Ihre DTOs aus Ihrem Entity Framework Datenmodell (EDMX).

    Grüße,
    Fabian Fernandez

    InformationsquelleAutor kzfabi
  4. 1

    DTO ist eine gute Praxis, die Minimierung der Menge an Daten, die Sie bei der übertragung über den Draht, um nur die relevanten Felder. Dies ist unter anderen Vorteilen. Kasse Automapper und die ProjectTo Methode, die automatisch konvertieren kann DAL DTO und Umgekehrt. ProjectTo unter der Motorhaube wird wählen Sie nur die Spalten enthalten, die in der mapping konfiguriert.

    https://github.com/AutoMapper/AutoMapper/wiki/Queryable-Extensions

    InformationsquelleAutor Greg R Taylor
  5. 0

    Mit Entity Framework code first-TT wie "EntityFramework Reverse POCO-Generator"
    (https://marketplace.visualstudio.com/items?itemName=SimonHughes.EntityFrameworkReversePOCOGenerator)
    zu generieren, Geschäftsmodelle verbunden, um-Datenbank Tabellen-schema in separaten Business-Entity-Modell-Bibliothek. Der TT ist in der Lage geändert werden, um benutzerdefinierte Attribute (wie DataMember, Serializable), die speziell WCF, Entity.

    Diese Weise könnten sowohl die Vorteile der DTO und EF POCO. Es könnte leicht zu pflegen Konsistenz zwischen Business-Modellen, Entitäten und die Datenbank-Tabellen.

    Der Grund ist, für die meisten Fälle, zu jeder Zeit ändern Sie die Datenbank-Tabelle Struktur, der Entwickler muss auch konsequent die Business-Modell-Struktur (DTO hier). Es gibt zusätzliche arbeiten zur Aufrechterhaltung Mapper.

    Wenn der Datenbank-Zugriff-Schicht-Modell (EF-POCO hier) die lose Kopplung mit DTO-Modell. Entwickler wird sehr schwierig sein, zu erkennen, die potenziellen Fehler, die nicht in der Zusammenstellung mal speziell für die Aufrechterhaltung der bestehenden enterprise-level-Anwendungen.

    Wenn wir zusätzliche benutzerdefinierte Eigenschaften für Business-Modell Entitäten, sind wir in der Lage, die partielle Klasse mit benutzerdefinierten Eigenschaften.

    Sind wir noch Mapper zu konvertieren EF POCO-Entität DTO Element, wenn es benötigt wird. Aber mein Punkt ist, versuchen zu minimieren Missbrauch mit Mappern, die nur tun, duplizieren funktioniert im Vergleich mit unmittelbar verbindlicher Daten in EF POCO-Modell.

    Da können wir generieren des EF-POCO-Entitäten in getrennten Business-Modell-Bibliothek, DTO Person ist in der Lage zu bleiben mit Ihnen im gleichen Business-Modell-Bibliothek. So, der Entwickler hat mehr Flexibilität, zu entscheiden, wie Sie zu benutzen sind.

    InformationsquelleAutor ChinaHelloWorld
Schreibe einen Kommentar