Konstantin | Dependency-Inversion-Principle

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