Ich stehe vor einer Design-Herausforderung, die ich einfach nicht befriedigend lösen kann. Ich habe eine Klassenbibliothek Assembly, die alle meine freigegebenen ORM-Objekte enthält (mit EntitySpaces-Framework). Diese Objekte werden in zwei oder mehr verschiedenen Anwendungen verwendet, weshalb sie in einer eigenen Baugruppe sind. Dieses Setup hat für mich mehr als 4 Jahre funktioniert.
Ich habe auch ein paar Anwendungen auf dem Composite Application Block (CAB) von Microsofts Patterns & amp; Übungsgruppe (P & amp; P). Ja, ich weiß, das ist wirklich alt, aber ich bin Teilzeit-Entwickler, One-Man-Shop und kann es mir nicht leisten, auf den aktuellen Stand der Technik zu aktualisieren.
Hier kommt mein Problem ins Spiel: Ich habe meine OO-Designfähigkeiten trainiert und versuche jedes Mal, wenn ich ein substanzielles Refactoring mache, von einem prozeduralen Ansatz zu einem mehr OO-Ansatz überzugehen. Natürlich liegt ein wichtiger Aspekt des OO-Designs darin, die Operationen in die Nähe der Daten zu bringen, mit denen sie arbeiten. Das bedeutet, dass meinen ORM-Objekten Funktionen hinzugefügt werden müssen, wo dies angebracht ist. Dies ist ein echter Kopfzerbrecher, wenn ich auch bedenke, dass ich den Object Builder DI-Container von P & amp; P in CAB verwende und dass ein großer Teil der Funktionalität, die ich in meine ORM-Objekte verschieben würde, Zugriff auf die von meinen Anwendungen offengelegten Dienste benötigt / p>
Mit anderen Worten, lassen Sie uns sagen, ich habe ein gemeinsames Geschäftsobjekt namens "Person" (Original, ich weiß) und ich habe zwei Anwendungen, die völlig verschiedene Dinge mit einer Person tun. Anwendung A stellt eine Reihe von Diensten zur Verfügung, die das Objekt Person DI hätte, um einige der Methoden zu übernehmen, die derzeit auf allen Ebenen der Dienste vorhanden sind. Anwendung B hat auch einen anderen Satz von Diensten, die die IT in das Personenobjekt eingefügt haben muss.
Wenn man bedenkt, wie der P & amp; P Object Builder Abhängigkeiten mit Attributdekoration und Typreflexion auflöst, sehe ich nicht, wie ich dies erreichen kann. Kurz gesagt, ich habe ein gemeinsames Objekt, das, wenn es in verschiedenen Anwendungen verwendet wird, ich Abhängigkeiten injizieren müsste, damit es bestimmte Operationen ausführen kann, die für diese Anwendung spezifisch sind.
Der einzige Ansatz, den ich mir vorstellen kann, ist, einen neuen Typ in Anwendung A & amp; B vom Objekt Person. Ich würde dann meine nicht-geteilte Funktionalität und DI-Code in dieses anwendungsspezifische spezialisierte Person-Objekt hinzufügen. Jetzt, da ich schreibe, dass es so offensichtlich erscheint, ist es immer noch meine einzige Lösung, die ich mir vorstellen kann und ich möchte hier fragen, ob jemand anders eine andere Lösung hat, die sie vorschlagen möchten?
Ein Problem, das ich mit meiner Lösung haben würde, ist, dass ich sehen kann, wie ich meinen geerbten Typ benennt - ich meine ... es ist eine Person, also wie würdest du es sonst nennen? Wie auch immer, hoffentlich hast du einige Ideen für mich.
Außerdem bin ich nicht gerade auf die aktuellen Technologien, die es gibt, und wirklich, um ehrlich zu sein, nur die zu verstehen, die ich gerade benutze. Also wenn ich etwas widersprüchliches oder verwirrendes gesagt habe, hoffe ich, dass du genug vom Rest des Posts verstehst, um zu bekommen, was ich frage.
Es klingt, als würden Sie das Prinzip der einheitlichen Verantwortung brechen.
Ein Person Objekt sollte nur die Daten für einen Personendatensatz enthalten. Die Dienste würden dann ein Objekt Person aufnehmen und es manipulieren, anstatt Methoden auf dem Objekt Person zu haben, das diese Manipulation ausgeführt hat.
Ein klassisches Beispiel wäre das Auffüllen des Objekts Person . Nehmen wir an, App A greift die Daten von einem WebService und App B nimmt sie aus einer Datenbank. In diesen Fällen hätte ich eine Art Storage -Dienst, den Sie aufrufen, um Ihr Person -Objekt zu erhalten. Die Implementierung dieses Speichers kann dann für jede Anwendung spezifisch sein und von der App in Ihr IOC eingegeben werden, anstatt zu versuchen, eine gemeinsame Schnittstelle in Ihrer freigegebenen Assembly zu haben.
Ich stimme Cameron MacFarland zu: Sie brechen SRP.
Natürlich ein wichtiger Aspekt des OO-Designs platziert die Operationen in der Nähe der Daten, mit denen sie arbeiten, bedeutet das meine ORM-Objekte müssen haben Funktionalität hinzugefügt, wo geeignet
Das Platzieren von Daten UND-Funktionalität von einer UND-Funktionalität aus B ist zwei Aufgaben zu viel. Das Einhalten von SRP führt fast immer dazu, dass Daten und Funktionen in separaten Klassen (Datenstrukturen und Objekte) getrennt werden. Daher ist die Verwendung von Cameron MacFarlands wahrscheinlich die beste Methode.
Ich könnte mir einige Ansätze vorstellen, um das Problem anzugehen.
Apporach1
%Vor% %Vor%Apporach2
%Vor%Das Personenschnittstellenprojekt muss einen Verweis auf IPerson1 und IPerson2 haben, oder Sie können IPerson1 und IPerson2 im Projekt Personenschnittstelle selbst deklarieren.
Tags und Links c# dependency-injection oop orm