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

Update: Reporting System

Browse Source
This commit is contained in:
Konstantin Hintermayer
2026-03-13 21:33:44 +00:00
committed by KoCoder
parent a535e73c3f
commit 1c1949381b
1 changed files with 5 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
View File

@@ -347,7 +347,7 @@ Es gibt 2 Möglichkeiten, wie man dieses Problem Lösen kann:
### Reporting System ### Reporting System
Eine weitere Anforderung der Diplomarbeit war es Einträge in Modulen wie der `Hall of Fame`, dem `Schwarzen Brett` und dem Premium Bereich (`Engineer Applications`) melden zu können. Am Anfang war es wichtig, dass jeder Schnell vorrankommt, allerdings haben wir die Kommunikation Teamintern ein wenig verschlafen und dadurch ein paar Funktionen doppelt geschrieben. Dadurch kam es zu inkonsistenzen in der Verwendung der Reporting Systeme. Eine weitere Anforderung der Diplomarbeit war es Einträge in Modulen wie der `Hall of Fame`, dem `Schwarzen Brett` und dem Premium Bereich (`Engineer Applications`) melden zu können. Am Anfang war es wichtig, dass jeder schnell vorrankommt, allerdings haben wir die Kommunikation Teamintern ein wenig verschlafen und dadurch ein paar Funktionen doppelt geschrieben. Dadurch kam es zu inkonsistenzen in der Verwendung der unterschiedlichen Reporting Systeme. Deswegen haben wir uns am Ende für eine globales Reporting System entschieden.
Angestrebt wurde folgender Ablauf für das Melden eines Eintrags: Angestrebt wurde folgender Ablauf für das Melden eines Eintrags:
```mermaid ```mermaid
@@ -368,11 +368,11 @@ sequenceDiagram
ReportingComponent->>-User: Done ReportingComponent->>-User: Done
``` ```
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 Trnnung 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.
Damit DI funktioniert muss der DI Consumer (`also das Modul, welches das Reporting System einbinden möchte`) das Interface zur Kompilierzeit sehen. Um das zu erreichen haben wir 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 Modul installiert 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 haben wir 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. 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 injezierte Klasse.
```razor ```razor
@inject IReportUI ReportingComponent @inject IReportUI ReportingComponent
@@ -384,14 +384,7 @@ Die Implementierung des IReportingComponents stellt nur eine Property (`ReportTy
} }
``` ```
IReportUI muss auch bereitgestellt werden, dass passiert im Startup.cs des Reporting Moduls (Admin Modul) Die Bereitstellund des Moduls geschieht im `AdminModules` Modul.
```c#
if (!services.Any(s => s.ServiceType == typeof(IReportUI)))
{
services.AddScoped<IReportUI, ReportComponent>();
}
```
## Event Registration ## Event Registration
## Schwarzes Brett ## Schwarzes Brett