Ich arbeite an einem Projekt, das die Abhängigkeitsinjektion über Ninject verwendet. Bis jetzt funktioniert es sehr gut, und ich mag DI sehr, aber jetzt habe ich entschieden, dass ich einige Objekte serialisieren muss, und es fällt mir schwer, das nach DI-Mustern zu tun.
Sagen wir, ich habe eine Klasse namens Foo, die eine Liste von Bars hat und sie durch eine Fabrik wie folgt macht:
%Vor% Hier ist Bar, die gemacht wird, wenn _barFactory.MakeBar() aufgerufen wird. Ich möchte, dass Bar serialisierbar ist:
Beachten Sie, dass Bar eine eigene Fabrik und eine Sammlung von Gurken hat. Hier ist das Problem: Wenn der Deserialisierungskonstruktor von Bar aufgerufen wird, habe ich keine Möglichkeit, eine weitere PickleFactory zu bekommen. Die ursprüngliche PickleFactory wurde Bar von der BarFactory übergeben, aber der Deserialisierungskonstruktor wurde nicht von BarFactory aufgerufen.
Mein aktueller Plan zur Lösung dieses Problems wäre, alle serialisierbaren Elemente von Bar in eine eigene Klasse namens BarDataObject zu extrahieren. Dann würde ich das BarDataObject serialisierbar machen, aber nicht Bar selbst. Ich würde BarFactory eine Funktion hinzufügen, die ein BarDataObject als Parameter akzeptiert und eine Bar für Sie erstellt, die alle Informationen aus dem BarDataObject enthält.
Nehmen wir jedoch an, dass Pickle auch über Serviceklassen verfügt, die es von der Factory erhalten hat, die es erstellt haben, die auch nicht serialisiert werden können. Also müsste ich auch ein DataObject aus Pickle extrahieren, und mein BarDataObject müsste ein PickleDataObject festhalten. Und angenommen, Pickle hat eine Mitgliedsvariable mit einer Mischung aus Daten und Services? Ich müsste dafür auch ein DataObject erstellen und pflegen. Das scheint ein echter Schwachpunkt zu sein, vor allem wenn man bedenkt, dass mein Projekt viele andere Dinge hat, die ich serialisieren muss, und sie werden wahrscheinlich das gleiche Problem haben.
Gibt es also eine bessere Lösung? Mache ich etwas falsch, DI-weise? Ich habe gerade angefangen, mit DI und Ninject zu arbeiten, aber ich kann niemanden finden, der eine gute Möglichkeit gefunden hat, Objekte zu serialisieren, denen Service-Klassen hinzugefügt wurden.
Meiner Erfahrung nach sollten nur Serviceklassen Abhängigkeiten haben und Serviceklassen sollten niemals serialisiert werden.
Die Tatsache, dass Sie eine Klasse haben, die Sie serialisieren möchten, die aber auf einem injizierten Service beruht, scheint mir ein Code-Geruch zu sein.
Es ist schwierig, genau zu sagen, was Sie mit Bar erreichen wollen, aber von dem, was ich sehen kann, würde ich vorschlagen, Pickle zu einem POCO zu machen und ein List<Pickle> anstelle eines benutzerdefinierten% zu verwenden. co_de% class.
Oder, wenn Bar neben den Pickles auch andere serialisierbare Informationen haben soll, machen Sie Bar ein POCO mit einer Pickles-Eigenschaft:
Da POCOs keine Abhängigkeiten haben, sollten sie keine Fabriken benötigen, daher sollte diese Klasse vollständig serialisierbar sein. Wenn komplexe Funktionen in Bar s und Bar s ausgeführt werden sollen, sollten sie in separate Dienstprogramme abstrahiert werden, die Pickle s und Bar s als Methodenparameter verwenden.
Tags und Links c# serialization dependency-injection ninject