DataContracts mit Verhalten

Question

Wie schlimm ist das? Ich habe unzählige Artikel gelesen und niemals abstrakte DataContracts mit Verhalten erstellt, aber es scheint, dass dies ein Problem lösen wird, das mich davon abhält, Fabriken überall zu erstellen, um eine Unterklassenimplementierung zu bestimmen. Meine Frage ist, werde ich bestraft, wenn ich beschließe, meinen Datenverträgen ein Verhalten hinzuzufügen? Natürlich können sie nicht konsumiert werden und sind dazu da, bestimmte Operationen auszuführen, die für diesen Unterklasse-Typ spezifisch sind, bevor Repository-Aufrufe aufgerufen werden und Daten persistiert werden. Ich kann "Manager" -Klassen für jede Unterklasse erstellen, aber das versetzt mich zurück in Fabriken und ich versuche einen polymorpheren Ansatz. Danke im Voraus.

Answer 1

Warum können Sie Ihren Datenkontrakt (MyDataContract) nicht klassisch erstellen, sondern nur Datenfelder und sonst nichts, und daraus dann Ihre Verhaltensklasse ableiten?

public class BehaviorialClass : MyDataContract 
{ 
..... 
} 

Auf diese Weise haben Sie eine schöne, saubere Trennung von Bedenken, Ihre Daten Vertrag nicht „verschmutzt“ durch Verhalten kann es nicht wirklich mit ohnehin beschäftigen .....

Marc

Answer 2

Ein guter Kompromiss, um das Verhalten direkt in Ihre DataContracts zu setzen, wäre das Definieren von Verhalten als extension methods entweder in der gleichen Assembly wie Ihre Contracts oder in einer anderen Assembly. Optional können Erweiterungsmethoden in einem separaten Namespace von den Verträgen platziert werden, um die Trennung von Daten und Verhalten weiter zu isolieren.

Auf diese Weise werden Ihre Verträge sauber gehalten, aber zur gleichen Zeit, .NET Verbraucher Ihrer Verträge hätten eine einfache Möglichkeit, zusätzliche Funktionen in Bezug auf diese DataContracts zu importieren.

Answer 3

Sie können alle gewünschten Verhaltensweisen zu Ihren Datenverträgen hinzufügen. Sie sollten eindeutig dokumentieren, dass das Verhalten für die Kunden nicht sichtbar ist, oder jemand wird später enttäuscht sein. Dokumentieren Sie auch, dass darauf geachtet werden muss, dass dem Datenvertrag keine implementierungsabhängigen Daten hinzugefügt werden, da dies nichts ist, was Sie an die Clients weitergeben möchten.

Alles in allem denke ich, dass es besser wäre, Datenverträge als Datenverträge zuzulassen und das Verhalten aus ihnen herauszulassen.

Answer 4

Irgendwann werden Sie MemberwiseClone verwenden und Schnittstellen ohne unnötige zwischenzeitliche Datenübersetzung implementieren wollen (und noch schlimmer, unnötige WARTUNG). Erweiterungsmethoden sind, wenn Sie buchstäblich keine Kontrolle über die Objektdefinition haben, aber trotzdem objektorientierte Sprachkenntnisse benötigen; Sie fügen in jeder anderen Situation viel Arbeit hinzu und streuen Klassendefinitionen schlechter als C/C++. Buck die "Trends" und tun, was für Sie funktioniert, können Sie nur ein Muster entdecken, das das ganze Ballspiel ändert (wie Jeffrey Richter AsyncEnumerator).