92 lines
3.3 KiB
Markdown
92 lines
3.3 KiB
Markdown
---
|
|
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 |