Ich habe hier etwas mit 'Plugins' gelesen. So (und mit noSQL) wurde eine polymorphe Produktdatenbank umgesetzt. Das Problem hier waren die sehr unterschiedlichen Eigenschaften, die wir in einem
EVAM umgesetzt hatten.
Edit: Das EVAM ist eigentlich ein
SQL-Antipattern, weil es in der Masse grottenlahm ist, aber wenn es nicht zu komplex ist, geht es noch.
Erschwerend (und damit für dich interessant) war die Tatsache, das es sich bei den Produkten um sehr komplexe elektrische Komponenten handelt, die allesamt Formeln und Algorithmen zur Berechnung physikalischer und geometrischer Eigenschaften benötigen. Weiterhin sind Eingabe und Designdialoge mit 40-100 Eingabefeldern je Produktkategorie nötig.
Zusätzlich war noch eine Skriptengine eingebaut, damit der Endanwender bestimmte Eigenschaften anhand anderer Eigenschaften ausrechnen kann.
Lösung: Plugins zur Berechnung, EVAM für die Daten und ASP.NET für die Dialoge. Alles in einer Produktklassentabelle konfiguriert. Wenn nun Produkt X bearbeitet werden soll, wird in in der Tabelle das Berechnungsplugin sowie der Dialog geladen und ausgeführt.
Bei Dir wäre das Ähnlich, wobei die Eigenschaften der Leistungen vielleicht nur 1-5 wären, wobei vielleicht nur 1-2 für den Anwender eingebbar sind. Damit würde dein individueller Dialog vielleicht nur eine Liste mit Textboxen sein.
Und die Businesslogik würde ich entweder skripten oder in einer
DLL vorhalten....
Eine Skriptengine bietet dir die Möglichkeit, zur Laufzeit das Verhalten anzupassen.