Was ist das beste Verfahren für die Übermittlung von Daten an den Kunden? POCO oder DTO?

Question

Ich beginne ein Projekt mit EF 4 und POCO.

Was ist die beste Vorgehensweise für die Übermittlung von Daten an den Kunden? Soll ich den POCO senden oder sollte ich stattdessen ein DTO verwenden?

Gibt es irgendwelche Probleme, auf die ich achten sollte, wenn ich die Entität (die vom Kontext getrennt ist) an den Client sende?

Ist es empfehlenswert, die POCO an die Client-Schicht zu senden?

Answer 1

Ich glaube, dass wir hier 2 Definitionen vermischen, die nichts miteinander zu tun haben.

DTO oder Data Transfer Object ist ein Entwurfsmuster, mit dem man Daten zwischen Schichten übertragen kann, und auch sie haben kein Verhalten. Martin Fowler erklärt dies sehr gut unter: http://www.martinfowler.com/eaaCatalog/dataTransferObject.html

Auf der anderen Seite haben wir POCO oder Plain Old CLR Object. Aber um über POCO zu sprechen, müssen wir wissen, wo es angefangen hat, nämlich bei POJO, oder Plain Old Java Object. Martin Fowler hat mit zwei Partnern den Begriff geprägt und erklärt ihn hier: http://www.martinfowler.com/bliki/POJO.html

So können POCOs Verhalten und alles was Sie wollen haben. Es sind die gleichen allgemeinen Klassen, die Sie in Ihrer täglichen Basis schreiben, sie haben ihnen nur diesen Namen gegeben, um sie kurz und leicht zu merken.

Als Antwort auf Ihre zweite Frage denke ich, dass der beste Ansatz und derjenige, für den ich mich immer entscheide, darin besteht, DTOs vom Busines Layer an alles zu senden, was diesen nutzt (z.B.: Ihre Dienste, Website, Desktop-App, mobile App, etc.). Das liegt daran, dass sie kein Verhalten haben und in den meisten Fällen nicht viel mehr als nur Eigenschaften, so dass sie leichtgewichtig und ideal für die Verwendung in Diensten sind und natürlich keine sensiblen Daten aus Ihrem Unternehmen preisgeben.

Das heißt, wenn Sie planen, DTO zu verwenden, kann ich Ihnen empfehlen, EntitiesToDTOs, ein Entity Framework DTO-Generator, dass ich gerade vor kurzem bei CodePlex veröffentlicht, es ist frei und Open Source herunterladen. Gehen Sie zu http://entitiestodtos.codeplex.com

Answer 2

Für mich ist einer der Hauptgründe, EF4 mit POCO zu verwenden, die Tatsache, dass man keine brauchen DTOs. Ich kann die Verwendung von DTOs bei herkömmlichen EDMX-Dateien verstehen, bei denen die Entitäten ziemlich aufgebläht sind, aber dies ist nicht der Fall.

Ihr POCO muss natürlich serialisierbar sein, aber es sollte keine spezifischen Probleme beim Senden von POCO-Entitäten geben, die nicht auch bei DTOs auftreten.

Answer 3

Ich habe eine etwas andere Meinung als die oben genannten Meinungen. Ich glaube, DTO oder ViewModel ist immer noch für außerhalb der Server-Schicht benötigt. In der realen Welt Anwendung gibt es ein paar View Layer, die nur ein Domain Object benötigen, d.h. fast alle Views benötigen mehrere Domain Objects. Und all diese Domänenobjekte sind in einer DTO- oder ViewModel-Klasse verpackt. Aus diesem Grund bestehe ich darauf, dass DTO oder ViewModel immer noch benötigt werden, obwohl sie POCO sind.

Answer 4

Ich würde EF4 Entitäten als Geschäftsmodelle UND Ansichtsmodelle in einem betrachten. Sie implementieren zum Beispiel PropertyChanged bereits von Haus aus. Partielle Klassen können benutzerdefinierte Funktionen bereitstellen, wenn Sie diese benötigen. Spiegeln die Entitäten mit Ihrer eigenen Sicherheitsschicht schafft unnötige Arbeit und Wartung, meiner Meinung nach.

Ich bin ein Verfechter der Trennung von Geschäftslogik und allem anderen. Im Falle von EF4 ist die Arbeit jedoch bereits für Sie erledigt. Machen Sie sich verrückt.