From 588cff937cd94cd4d6137cda9a6398ea1280cf7f Mon Sep 17 00:00:00 2001 From: KoCoder Date: Wed, 11 Feb 2026 11:33:52 +0100 Subject: [PATCH] Konstantin | Dependency-Inversion-Principle --- ...dividueller-teil-Konstantin-Hintermayer.md | 92 +++++++++++++++++++ 1 file changed, 92 insertions(+) diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md index e69de29..cebfd87 100644 --- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md +++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md @@ -0,0 +1,92 @@ +--- +include_toc: true +gitea: none +--- + +# Technologie +## Entwicklung mit Asp.Net (Was ist Blazor? / Was ist Razor? / Kestrel) +## Was ist Oqtane? Architektur von Oqtane? +## Systemarchitektur (Postgres / Oqtane / Nginx ) +```mermaid +architecture-beta + group server(server)[Server] + + service db(database)[PostgreSQL] in server + service oqtane(server)[Oqtane] in server + service nginx(server)[NginX] in server + + service internet(cloud)[Internet] + + internet:R <--> L:nginx + nginx:R <--> L:oqtane + oqtane:R <--> L:db +``` +## Websockets und HTTP 1.1 + + +## Dependency injection + +### Dependency Inversion Principle [^1] +Das Dependency-Inversion-Principle (DIP / auf Deutsch: Abhängigkeits-Umkehr-Prinzip) ist eines von den 5 `SOLID` Prinzipien in der Softwareentwicklung. + +Das DIP unterscheidet zwischen high-level und low-level Modulen. +- Die high-level Module beschreiben die Applikations- / Buisnesslogik, ohne direkt mit den low-level Modulen zu interagieren, sondern lediglich auf abstraktionen. [^3] +- Die Abstraktionen sollen nicht von Implementierungsdetails abhängig sein, sondern die low-level Implementierung sollen gemäß der Abstraktionsschickt implemetiert werden. [^3] + +Ausgangslage ist eine Softwarearchitektur im Direct-Dependency-Graph Model. + +```mermaid +architecture-beta + service a(mdi:package-variant-closed)[Klasse A] + service b(mdi:package-variant-closed)[Klasse B] + service c(mdi:package-variant-closed)[Klasse C] + + a:R --> L:b + b:R --> L:c +``` +Bei diesem Beispiel ist die Klasse A ein high-level Modul, welches direkt auf die Klasse B referenziert, was das DI-Prinzip verbietet. +Das Problem dabei: Die einzelnen Klassen sind eng gekoppelt, was das austauschen von B mit einer anderen Klasse unmöglich macht. Genau dieses Problem wird vom DIP gelöst. + +```mermaid +architecture-beta + service a(mdi:package-variant-closed)[Klasse A] + service b(mdi:package-variant-closed)[Klasse B] + service ib(mdi:car-clutch)[Interface B] + service c(mdi:package-variant-closed)[Klasse C] + service ic(mdi:car-clutch)[Interface C] + + a:B --> T:ib + ib:R <-- L:b + b:B --> T:ic + ic:R <-- L:c +``` +Das high-level Modul ruft lediglich eine Abstraktion eines low-level Moduls auf, welche ein von einem, oder mehreren low-level Modulen implementiert worden ist. Für das high-level Modul ist es hier egal, welches low-level Modul die Implementierung bereitstellt. Dadurch erhält man einen viel modulareren Aufbau in der Software. Die einzelnen Module sind auch leichter austauschbar, testbar. Genau diese Modularität macht dependency injection möglich. + +### Microsoft Dependency Injection Framework + + +[^1]: https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles#dependency-inversion + +[^2]: https://blog.logrocket.com/dependency-inversion-principle/ + +[^3]: https://www.oodesign.com/dependency-inversion-principle + +[^5]: https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection/overview +# Projektmanagement +## Scrum +## YouTrack +## Gitea (mit Issues) +## Git +## Kommunikation + +# Learnings +## Probleme mit Oqtane +## Arbeitszeiteinschätzung (Zeitverzug) +## Teamleitung (Motivation / Downsizing) +## Produktion != Staging +## Sprints und Meetings (in Zukunft ja Asyncron + +# Modules +## Mass Mailer +## Event Registration +## Schwarzes Brett \ No newline at end of file