Wie schlimm ist es? 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. Vielen Dank im Voraus.
Sie können das gesamte gewünschte Verhalten 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 für Sie besser wäre, Datenverträge als Datenverträge zuzulassen und ihnen das Verhalten zu überlassen.
Warum können Sie Ihren Datenkontrakt (MyDataContract) nicht auf klassische Weise erstellen, nur Datenfelder, sonst nichts, und daraus dann Ihre Verhaltensklasse ableiten?
%Vor%Auf diese Weise haben Sie eine nette, saubere Trennung von Bedenken, Ihr Datenvertrag ist nicht durch Verhalten "verschmutzt", mit dem es sich sowieso nicht wirklich beschäftigen kann .....
Marc
Ein guter Kompromiss, um Verhalten direkt in Ihren DataContracts zu setzen, wäre das Definieren von Verhaltensweisen als Erweiterungsmethoden entweder in der gleichen Baugruppe wie Ihre Verträge oder in einer anderen Baugruppe. 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 .NET-Kunden Ihrer Verträge haben gleichzeitig eine einfache Möglichkeit, zusätzliche Funktionen in Bezug auf diese DataContracts zu importieren.
Irgendwann werden Sie MemberwiseClone verwenden und Schnittstellen ohne unnötige zwischengeschaltete Datenübersetzung (und noch schlimmer, unnötige WARTUNG) implementieren wollen. Erweiterungsmethoden sind, wenn Sie buchstäblich keine Kontrolle über die Objektdefinition haben, aber objektorientierte Geläufigkeit benötigen; Sie fügen in jeder anderen Situation viel Arbeit hinzu und streuen Klassendefinitionen schlechter als C / C ++. Verdoppeln Sie die "Trends" und tun Sie, was für Sie funktioniert, Sie könnten nur ein Muster entdecken, das das ganze Ballspiel verändert (wie Jeffrey Richters AsyncEnumerator).
Tags und Links wcf design datacontract