Wie oben beschrieben, implementiere ich eine mehrstufige Architektur, um mit WCF und Entity Framework 4 (mit poco) zu arbeiten. Da ich mit POCO bereits Beharrlichkeits-Ignoranz habe, muss ich DTO implementieren oder kann ich WCF auf seine reine Art benutzen?
Das Hauptzitat ist - Ich brauche DTO, um ein leichtes Objekt im Netzwerk zu übergeben, oder ich kann meine POCO-Entitäten verwenden.
Was ihr Jungs empfiehlt?
Es ist schwer zu beantworten, wenn Sie nicht definieren, was der "reine Weg" ist. Sprechen wir SOA pur oder WCF rein?
WCF-Proxys sind bereits DTOs, weil sie keine Geschäftslogik über Ihren Servicevertrag hinweg mit sich bringen. Das Erstellen einer weiteren DTO-Schicht über den von WCF generierten Proxyklassen erscheint redundant.
Die größte Frage, die Sie beantworten möchten, lautet: "SOA ist diese Lösung?". Sie können Ihre POCO-Entitäten nicht über Servicegrenzen hinweg freigeben, wenn Sie SOA-konform sein möchten. Bei SOA geht es um unterschiedliche Verträge.
Wenn Sie auf SOA-Basis gehen, verlieren Sie viel Funktionalität, weil die Klassen, mit denen Ihre Web-Tier die meiste Zeit arbeitet, dumme Proxies sein werden. Sie müssen eine Menge Logik wiederholen, und Sie haben viel von der Funktionalität "Metadaten, Konvention über Konfiguration" verloren, die MVC 2 bietet.
Wenn Sie das SOA-Modewort in den Shredder werfen, was Sie tun sollten ( Ссылка ), dann haben Sie viel leichter Zeit zu teilen Geschäftslogik und Metadateninformationen über mehrere Ebenen hinweg. Wenn der einzige Verbraucher Ihres Webdienstes Sie selbst ist, dann ist diese Methode wahrscheinlich die beste Wahl.
Hier können Sie DTOs verwenden, um anstelle der POCO-Entitäten über die Leitung zu senden. Der einzige Nachteil ist wieder, wiederholte Logik und viele Kesselplatte zeremoniellen Code, der nichts tut. Kommt wirklich auf die Größe Ihres Projekts an. Wenn es klein ist, vergiss DTOs, aber wenn du 20 Entwickler hast, die mit 200.000 LoC arbeiten, dann sind DTOs wahrscheinlich wert, erstellt zu werden.
Wie Jfar gesagt hat, hängt es davon ab, ob Sie zu dem sein werden, der nur den Service konsumiert, oder ob die Präsentationsebene nur Sie betreffen wird.
Wenn Sie das später tun, und Sie nur Ihren Dienst verwenden werden, können Sie Ihre POCOs über die Grenzen des WCF-Dienstes serialisieren. Dies ist etwas, was ich kürzlich getan habe und diesen Blogpost über das Erhalten geschrieben habe es funktioniert. Auf diese Weise können Sie die gleichen Entitäten in der App-Ebene sowie in der Präsentationsschicht verwenden.
Ich hoffe, es hilft.
Der beste Grund, ein DTO bei der Verwendung von WCF mit EF zu empfehlen, ist, dass EF-Datenbank-erste Klassen Implementierungsabhängigkeiten in Ihre Proxy-Klassen ziehen. Wenn Sie Code-First mit POCO-Klassen verwenden, sollte es keine Implementierungsabhängigkeiten geben.
Versuchen Sie, nur Ihre POCO-Klassen zurückzugeben, aber sehen Sie sich dann die generierten Proxy-Klassen genauer an. Stellen Sie sicher, dass in den Klassen, die Teil der EF-Infrastruktur sind, nichts vorhanden ist. Wenn die Proxy-Klassen sauber sind, sollten Sie alle festgelegt werden.
Tags und Links asp.net-mvc wcf c# dto