Diplomarbeit-Absolventenverein/pm
7
0
Fork 0
Code Issues 35 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

ReportingSystem: Open/Closed Principle

Browse Source
This commit is contained in:
Konstantin Hintermayer
2026-03-21 12:34:22 +01:00
parent bf6f69daab
commit e33f60dcea
1 changed files with 2 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
05-Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
View File

@@ -426,6 +426,8 @@ sequenceDiagram
Im oben dargestellten Ablaufdiagram werden das ReportingComponent und der ReportingHandler vom Reporting System über Dependency Injection bereitgestellt, nicht vom Modul selbst. Dadurch erreichen wir eine bessere Trennung der Zuständigkeiten und halten das S in SOLID ein: `Single responsibility`. Die Module sind jetzt nicht mehr für das Reporting selber verantwortlich, sondern müssen nur das Reportings System einbinden. Im oben dargestellten Ablaufdiagram werden das ReportingComponent und der ReportingHandler vom Reporting System über Dependency Injection bereitgestellt, nicht vom Modul selbst. Dadurch erreichen wir eine bessere Trennung der Zuständigkeiten und halten das S in SOLID ein: `Single responsibility`. Die Module sind jetzt nicht mehr für das Reporting selber verantwortlich, sondern müssen nur das Reportings System einbinden.
Darüber hinaus erfüllt dieses Design das **Open/Closed Principle**: Das Reporting-System ist offen für Erweiterungen (neue Module können einfach andocken), aber geschlossen für Modifikationen (der Kern des Reporting-Systems muss nicht für jedes neue Modul geändert werden).
Damit DI funktioniert muss für den DI Consumer (`also das Modul, welches das Reporting System einbinden möchte`) das Interface zur Kompilierzeit zur Verfügung stehen. Um das zu erreichen habe ich eine neue Klassenbibliothek erstellt: Sie heißt Interfaces wird per Gitea Actions automatisch in ein Nuget Paket gebaut und in der `Gitea Actions Nuget Registry` veröffentlicht. Dieses Nuget Paket wird dann in jedem notwendigen Modul als Dependency hinzugefügt und damit kann man Modulübergreifend auf die Services und das IReporting Component zugreifen. Damit DI funktioniert muss für den DI Consumer (`also das Modul, welches das Reporting System einbinden möchte`) das Interface zur Kompilierzeit zur Verfügung stehen. Um das zu erreichen habe ich eine neue Klassenbibliothek erstellt: Sie heißt Interfaces wird per Gitea Actions automatisch in ein Nuget Paket gebaut und in der `Gitea Actions Nuget Registry` veröffentlicht. Dieses Nuget Paket wird dann in jedem notwendigen Modul als Dependency hinzugefügt und damit kann man Modulübergreifend auf die Services und das IReporting Component zugreifen.
Die Implementierung des IReportingComponents stellt nur eine Property (`ReportType`, welche den TypeName der Razor Komponente zurückliefert, damit Dynamic Component sie laden kann) und eine Methode (`ConstructParameterList`, welche das Parameter Dictionary erstellt. Nur zwecks Typensicherheit eingefügt) bereit. Mit dem Dynamic Component von Razor ist es möglich, per C# Code unterschiedliche Komponenten zu rendern und damit auch die per DI injizierte Klasse. Die Implementierung des IReportingComponents stellt nur eine Property (`ReportType`, welche den TypeName der Razor Komponente zurückliefert, damit Dynamic Component sie laden kann) und eine Methode (`ConstructParameterList`, welche das Parameter Dictionary erstellt. Nur zwecks Typensicherheit eingefügt) bereit. Mit dem Dynamic Component von Razor ist es möglich, per C# Code unterschiedliche Komponenten zu rendern und damit auch die per DI injizierte Klasse.