Verwendung von DTOs und BOs

Question

Ein Bereich von Frage für mich über DTOs/BOs ist, wann die DTOs übergeben/zurückgegeben werden und wann die BOs zurückgegeben/zurückgegeben werden sollen.

Meine Bauchreaktion besagt, dass ich immer NHibernate den DTOs und nicht BOs zuordnen und immer die DTOs übergeben/zurückgeben soll. Dann, wann immer ich Geschäftslogik durchführen musste, würde ich mein DTO in ein BO umwandeln.

Die Art, wie ich dies tun würde ist, dass mein BO einen Konstruktor haben würde, der einen Parameter nimmt, der der Typ meiner Schnittstelle ist (die die erforderlichen Felder/Eigenschaften definiert), die sowohl mein DTO als auch BO als das einzige implementieren Streit.

Dann wäre ich in der Lage, meine BO durch Übergabe der DTO im Konstruktor (da beide mit der gleichen Schnittstelle implementieren, haben sie beide mit den gleichen Eigenschaften) und dann in der Lage sein, meine Geschäftslogik mit diesem BO durchzuführen . Ich hätte dann auch eine Möglichkeit, ein BO in ein DTO umzuwandeln.

Allerdings habe ich auch gesehen, wo Leute scheinen nur mit BOs arbeiten und nur mit DTOs im Hintergrund arbeiten, wo für den Benutzer, es sieht aus als gäbe es keine DTOs.

Welche Vorteile/Nachteile gibt es bei dieser Architektur vs immer BOs verwenden?

Sollte ich immer DTOs oder BOs weitergeben/zurückgeben oder mischen und abgleichen (scheint zu sein, dass Mischen und Anpassen verwirrend werden könnte)?

Answer 1

Vielleicht finden Sie dies: http://automapper.codeplex.com/ auch nützlich.

Answer 2

Es hängt davon ab, was Sie erreichen möchten. Ich kann Ihnen sagen, was ich selbst mache - ich habe sowohl das DTO als auch das BO in NHibernate gemappt, aber die DTOs sind als unveränderlich zugeordnet, so dass ich die Datenbank nicht versehentlich aktualisiere, ohne ein BO zu verwenden.

Alle in den WebServices verfügbaren Abfragen geben DTOs zurück.

Immer wenn ich von einem DTO aktualisiere, mache ich ein UnitOfWork, wo ich das BO lade, aktualisiere die Eigenschaften vom DTO und speichere es, wenn es noch gültig ist.

Auf dem Client, ich erstelle das BO aus dem DTO (AutoMapper ist definitiv eine gültige Wahl hier), wenn der Client es ändern muss. Das BO hat einen ctor, der alle Argumente annimmt, um es ähnlich wie NHibernate zu erstellen. Die Vorteile sind: * Vollständige Kontrolle über die Menge der Daten, die über die Leitung geht (Die DTOs sind in der Regel abgeflacht, so dass nur die ID der zugeordneten Klassen im ersten Anruf gesendet wird). * Ich muss nicht die gleichen Eigenschaften in beiden haben * Ich kann Lazy-loading mischen und anpassen, wie ich * Ich kann skalare Abfragen und andere berechnete Eigenschaften in den DTOs verwenden, ohne sie in der BO zu erstellen. * Ich kann mehrere verschiedene DTOs pro BO für verschiedene Szenarien haben.

Also, ich denke, dass das Mischen und Anpassen qualifizieren würde, aber mit klaren Richtlinien, wo ich tun, was :-)

Hoffnung, das hilft.

Answer 3

Ich weiß, das ist eine ziemlich alte Frage, aber lassen Sie mich meine "Zehn Cent" über dieses Thema geben.

Bei der Arbeit mit einem MVC-Projekt (sogar mit Entity Framework oder NHibernate), verwende ich POCO für Persistenz und DTO/ViewModels für die Zwischenarbeit, wegen der flacheren Verhalten, weniger Daten auf Draht und nicht zuletzt wertvoll), sie stellen keine Beziehungen zwischen Objekten in irgendeiner Weise aus.

Ich weiß, dass dies wie eine "Silberkugel" klingen mag, aber zumindest funktioniert es für eine Weile für mich.

(verzeihen Sie einige Englisch Fehler =))