.NET Teilklassen vs. Vererbung

Question

Okay, wir haben hier ein Dienstprogramm, das Geschäftsmodellklassen aus unseren Datenbanktabellen und -ansichten generiert, die einem ORM ähnlich sind (aber nicht ganz genau). Bei der Pflege ist mir aufgefallen, dass sich die Daten in den Schemata wahrscheinlich nicht sehr ändern werden. Die Funktionalität könnte jedoch. Wir möchten möglicherweise zusätzliche Funktionalität auf dem Weg hinzufügen. Wir möchten vielleicht etwas von dieser Funktionalität generieren, und wir möchten sie möglicherweise erweitern.

Die Klassen, die wir erstellen, befinden sich in einer Klassenbibliothek für die Verwendung durch andere Bibliotheken und Anwendungen. Keine große Überraschung dort. Aber der Stumper ist hier, wie generierte Klassen so entworfen werden, dass wir so wenig Code wie möglich zerstören, wenn wir eine Klasse neu generieren. Wenn beispielsweise Code zu einer Eigenschaft hinzugefügt wurde (die eine Spalte in einer Datenbanktabelle darstellt), möchten wir diese nicht verlieren.

So gibt es zwei Ansätze, die den Sinn springen:

Klassisches Erbe, wo die ganze Sache in einer einzigen „monolithischen“ Klasse gemacht wird und die Verbraucher sind frei, die Basisimplementierung außer Kraft zu setzen. Dies wird jedoch von Zeit zu Zeit etwas schwierig und wirft häufig Casting-Kopfschmerzen auf. Wenn die abgeleitete Klasse nicht vorsichtig ist und vergisst, Basisklassenfunktionen aufzurufen, können die Dinge schnell schiefgehen.

Teilklassen. In diesem Schema trennen wir das Geschäftsobjekt in verschiedene Teile: die Eigenschaften (die den Spalten zugeordnet werden) und die Verhaltensweisen. Verhaltensweisen könnten sogar weiter in generierte Verhaltensweisen und benutzerdefinierte Verhaltensweisen unterteilt werden. Das Problem mit diesem Ansatz ist, wie Sie sehen können, seine inhärente Komplexität. Außerdem gibt es das Problem der Namensgebung.

Hier ist meine Frage für Sie Leute: Wenn Sie mit einem solchen Szenario (wenn Sie jemals haben), oder wenn Sie mit einem solchen Szenario vorgestellt wurden, welche Lösungen würden Sie in Betracht ziehen, und warum?

Answer 1

Der ganze Grund, warum Partial Classes in .Net enthalten sind, soll die Verwendung von Codegenerierungswerkzeugen erleichtern.

Wenn Sie Code generieren, verwenden Sie Teilklassen. Es ist wirklich so einfach. Warum würden Sie das Risiko eingehen, dass der Code im Lauf der Zeit neu generiert werden muss und Sie eine Menge Arbeit aufwenden müssten, um ihn mit Anpassungen neu zu aktualisieren?

Ich finde nicht, dass es auch bei Partials viel Komplexität gibt - es ist einfach eine Klasse, die auf mehrere Dateien aufgeteilt ist. Generierter Code in einer Datei, benutzerdefinierter Code in der anderen.

Answer 2

Ich würde Teil Klassen Pfad gehen. Nur weil es natürlicher ist, ein Objekt in viele Teile zu teilen. Sogar Linq2Sql verwendet Teiltöne. Kämpfe mit Komplexität mit Mustern und richtigen Konventionen. Und es ist einfacher, eine partielle Aktualisierung (wenn der generierte Code gut strukturiert ist) für partielle Klassen durchzuführen.

Wenn Sie keinen Code generieren - gehen Sie Klassenvererbung Weg (eigentlich würden Sie gezwungen sein, weil Partials nicht über verschiedene Assemblys hinweg funktionieren).

Answer 3

Dies ist genau das Problem, dass partielle Klassen vorhanden sind, um zu lösen. Ich denke, dass Sie sie für praktische Zwecke vielleicht ein wenig zu weit abbrechen. Meine Bauchreaktion, ohne die feineren Details Ihrer Anwendung zu kennen, wäre die Verwendung einer partiellen Klassendatei für den gesamten generierten Code einer Klasse und einer zweiten Datei für den von Hand erstellten Code. Erstelle eine Namenskonvention für generierte Teilklassen und bleibe dabei.

Answer 4

Wenn Sie einen Typ haben, der serialisiert werden soll (zu xml) und einige Funktionen hinzufügen möchten, müssen Sie partielle Klasse und nicht Vererbung verwenden. Dank /// M

Answer 5

Sie sagen:

ähnlich ist (aber nicht ganz genau wie) ein ORM

ich um die Wartungskosten für die aktuelle Lösung einige die Aussichten Zahlen ziehen würde (was ich vermute, ist signifikant) dann wählen Sie ein ORM, schreiben Sie eine Proof of Concept-Lösung und erstellen Sie Vergleichszahlen, um das zu erhalten. Ich bin mir nicht sicher, was dieses kundenspezifische Paket in der Art der Wartung, des Hochfahrens und des Entwicklers Kauf in kostet, aber ich würde für ein "Gewohnheits" Produkt wie dieses überhaupt nicht gehen. Das Wissen ist nicht übertragbar, das Fehlerrisiko ist hoch (immer der Fall bei der Codegenerierung) und Sie sind an die Intrakavität der zugrunde liegenden Datenbank gebunden.