552 lines
10 KiB
Markdown
552 lines
10 KiB
Markdown
# Poker-Plattform Architektur-Dokumentation
|
|
|
|
## 1. Ziel des Projekts
|
|
|
|
Dieses Projekt ist eine Online-Poker-Plattform als Desktop-Anwendung mit `WPF` auf dem Client.
|
|
Die Anwendung soll mehrere Benutzer unterstuetzen, die sich registrieren, einloggen, Freunde verwalten, private Lobbys erstellen und gemeinsam Texas Hold'em spielen koennen.
|
|
|
|
Die Architektur ist so ausgelegt, dass sie fuer ein MVP einfach genug bleibt, aber spaeter um weitere Features wie Ranking, Store, Matchmaking, Mini-Chat und erweiterte Profile erweitert werden kann.
|
|
|
|
## 2. Hauptanforderungen
|
|
|
|
### Must have
|
|
|
|
- Registrierung
|
|
- Login
|
|
- Friendship Request
|
|
- Erstellung von privaten Lobbys
|
|
- Poker-Gameplay
|
|
- vorbereitetes Monetization-System
|
|
- Logging-System
|
|
- Notification-System
|
|
|
|
### Nice to have
|
|
|
|
- Ranking-System
|
|
- Mini-Chat
|
|
- App-Settings
|
|
- Matchmaking
|
|
- Advanced Profile
|
|
- Store
|
|
|
|
## 3. Technologie-Stack
|
|
|
|
### Client
|
|
|
|
- `WPF`
|
|
- `SignalR Client`
|
|
|
|
### Server
|
|
|
|
- `ASP.NET Core`
|
|
- `SignalR`
|
|
- C# Service- und Business-Logik
|
|
|
|
### Datenzugriff
|
|
|
|
- `ADO.NET`
|
|
- `Microsoft.Data.SqlClient`
|
|
|
|
### Datenbank
|
|
|
|
- `SQL Server`
|
|
|
|
## 4. Grundidee der Architektur
|
|
|
|
Die Anwendung besteht aus drei Hauptteilen:
|
|
|
|
1. `WPF Client`
|
|
2. `Serverprozess`
|
|
3. `SQL Server`
|
|
|
|
### 4.1 WPF Client
|
|
|
|
Der Client ist nur fuer die Darstellung und Benutzerinteraktion verantwortlich.
|
|
|
|
Aufgaben des Clients:
|
|
|
|
- Login- und Registrierungsoberflaechen anzeigen
|
|
- Freundesliste und Freundschaftsanfragen darstellen
|
|
- private Lobbys anzeigen und verwalten
|
|
- Pokertisch visualisieren
|
|
- Spieleraktionen an den Server senden
|
|
- Benachrichtigungen live anzeigen
|
|
|
|
Der Client darf keine kritischen Spielregeln selbst kontrollieren.
|
|
Er zeigt nur Daten an und sendet Benutzerabsichten wie `Raise`, `Call`, `Fold` oder `Lobby erstellen`.
|
|
|
|
### 4.2 Serverprozess
|
|
|
|
Der Serverprozess ist das zentrale Gehirn der Anwendung.
|
|
|
|
Er enthaelt:
|
|
|
|
- Session-Logik
|
|
- Social-Logik
|
|
- Lobby-Logik
|
|
- Poker-Logik
|
|
- Notification-Logik
|
|
- Logging-Logik
|
|
- Repository-Zugriffe auf SQL Server
|
|
|
|
Der Server:
|
|
|
|
- nimmt Anfragen vom Client entgegen
|
|
- prueft Regeln und Berechtigungen
|
|
- liest und schreibt Daten in SQL Server
|
|
- sendet Live-Updates ueber SignalR an alle relevanten Clients
|
|
|
|
### 4.3 SQL Server
|
|
|
|
SQL Server speichert den dauerhaften Zustand der Anwendung.
|
|
|
|
Dazu gehoeren:
|
|
|
|
- Benutzer
|
|
- Sessions
|
|
- Freundschaften
|
|
- Lobbys
|
|
- Pokerhaende
|
|
- Handaktionen
|
|
- Notifications
|
|
- Wallet-Daten
|
|
- Logs
|
|
|
|
## 5. Warum kein direkter Vollzugriff des Clients auf die Datenbank?
|
|
|
|
Auch wenn eine WPF-App technisch direkt mit einer Connection String an SQL Server verbunden werden kann, ist das fuer ein Online-Poker-System nicht die beste Loesung.
|
|
|
|
Gruende:
|
|
|
|
- Spielregeln koennen sonst leichter umgangen werden
|
|
- Sicherheitslogik waere im Client sichtbar
|
|
- Benutzer koennten gezielt Requests manipulieren
|
|
- Turn-Order und Anti-Cheat werden schwieriger
|
|
- Live-Funktionen wie Lobby-Updates und Notifications brauchen ohnehin einen Server
|
|
|
|
Deshalb gilt in diesem Projekt:
|
|
|
|
- `WPF` ist der Client
|
|
- `ASP.NET Core + SignalR` ist der Serverteil
|
|
- `ADO.NET` verbindet den Server mit `SQL Server`
|
|
|
|
## 6. Geplante Solution-Struktur
|
|
|
|
Empfohlene Projektaufteilung:
|
|
|
|
### `Poker.Client`
|
|
|
|
WPF-Anwendung mit:
|
|
|
|
- Views
|
|
- ViewModels
|
|
- Client-Services fuer SignalR
|
|
- UI-State
|
|
|
|
### `Poker.Server`
|
|
|
|
ASP.NET-Core-Anwendung mit:
|
|
|
|
- REST-Endpunkten fuer normale Operationen
|
|
- SignalR-Hubs fuer Echtzeitkommunikation
|
|
- Services fuer Geschaeftslogik
|
|
|
|
### `Poker.Core`
|
|
|
|
Klassenbibliothek fuer Business-Logik:
|
|
|
|
- Poker-Regeln
|
|
- Lobby-Regeln
|
|
- Social-Regeln
|
|
- Session-Regeln
|
|
- Notification-Regeln
|
|
|
|
Diese Schicht soll moeglichst unabhaengig von UI und SQL bleiben.
|
|
|
|
### `Poker.Data`
|
|
|
|
Klassenbibliothek fuer Datenzugriff:
|
|
|
|
- `SqlConnectionFactory`
|
|
- Repositories
|
|
- SQL-Statements
|
|
- Mapper
|
|
- Transaktionslogik
|
|
|
|
### `Poker.Contracts`
|
|
|
|
Gemeinsame DTOs und SignalR-Modelle zwischen Client und Server.
|
|
|
|
## 7. Schichtenmodell
|
|
|
|
### Client-Seite
|
|
|
|
```text
|
|
WPF UI
|
|
-> ViewModel
|
|
-> Client Service
|
|
-> SignalR / HTTP
|
|
```
|
|
|
|
### Server-Seite
|
|
|
|
```text
|
|
Hub / Controller
|
|
-> Application Service
|
|
-> Domain Logic
|
|
-> Repository
|
|
-> SQL Server
|
|
```
|
|
|
|
## 8. Feature-Bereiche
|
|
|
|
### 8.1 Registrierung und Login
|
|
|
|
Der Benutzer kann:
|
|
|
|
- ein Konto erstellen
|
|
- sich einloggen
|
|
- eine Session erhalten
|
|
|
|
Serverseitige Aufgaben:
|
|
|
|
- Benutzername und E-Mail pruefen
|
|
- Passwort sicher hashen
|
|
- Session erzeugen
|
|
- Login-Audit loggen
|
|
|
|
Empfohlene Tabellen:
|
|
|
|
- `Users`
|
|
- `UserSessions`
|
|
|
|
### 8.2 Friendship Requests
|
|
|
|
Ein Benutzer kann:
|
|
|
|
- einen anderen Benutzer als Freund anfragen
|
|
- Anfrage annehmen
|
|
- Anfrage ablehnen
|
|
- Freund entfernen
|
|
|
|
Serverseitige Regeln:
|
|
|
|
- keine Selbstanfrage
|
|
- keine doppelten offenen Anfragen
|
|
- keine doppelte Freundschaft
|
|
|
|
Empfohlene Tabellen:
|
|
|
|
- `FriendRequests`
|
|
- `Friendships`
|
|
|
|
### 8.3 Private Lobby
|
|
|
|
Der Benutzer kann:
|
|
|
|
- eine private Lobby erstellen
|
|
- Freunde einladen
|
|
- einer Einladung folgen
|
|
- die Lobby verlassen
|
|
|
|
Der Host kann:
|
|
|
|
- Spiel starten
|
|
- Lobby schliessen
|
|
- Spieler verwalten
|
|
|
|
Empfohlene Tabellen:
|
|
|
|
- `Lobbies`
|
|
- `LobbyMembers`
|
|
- `LobbyInvites`
|
|
|
|
### 8.4 Poker
|
|
|
|
Poker wird serverautoritativ umgesetzt.
|
|
|
|
Das bedeutet:
|
|
|
|
- der Client schlaegt nur Aktionen vor
|
|
- der Server entscheidet, ob die Aktion erlaubt ist
|
|
- der Server aktualisiert die Hand
|
|
- der Server broadcastet den neuen Zustand
|
|
|
|
Erste Variante:
|
|
|
|
- `No-Limit Texas Hold'em Cash Game`
|
|
|
|
Wichtige Regeln:
|
|
|
|
- korrekte Zugreihenfolge
|
|
- Blind-Struktur
|
|
- gueltige Aktionen pro Runde
|
|
- Pot-Berechnung
|
|
- Showdown
|
|
|
|
Empfohlene Tabellen:
|
|
|
|
- `Tables`
|
|
- `Hands`
|
|
- `HandPlayers`
|
|
- `HandActions`
|
|
|
|
### 8.5 Logging-System
|
|
|
|
Es werden zwei Arten von Logging unterschieden:
|
|
|
|
#### Technisches Logging
|
|
|
|
Fuer Fehler, Exceptions, Performance und Diagnose.
|
|
|
|
#### Fachliches Logging / Audit Logging
|
|
|
|
Fuer wichtige Benutzer- und Spielfluss-Ereignisse:
|
|
|
|
- Registrierung
|
|
- Login
|
|
- Freundschaftsanfrage
|
|
- Lobby erstellt
|
|
- Lobby beigetreten
|
|
- Spiel gestartet
|
|
- Pokeraktion ausgefuehrt
|
|
|
|
Empfohlene Tabelle:
|
|
|
|
- `AppLogs`
|
|
|
|
### 8.6 Notification-System
|
|
|
|
Benachrichtigungen werden in Echtzeit ueber `SignalR` verschickt und zusaetzlich in SQL gespeichert.
|
|
|
|
Anwendungsfaelle:
|
|
|
|
- Freundschaftsanfrage erhalten
|
|
- Freundschaftsanfrage angenommen
|
|
- Lobby-Einladung erhalten
|
|
- Lobby-Status geaendert
|
|
- Systemmeldung
|
|
|
|
Empfohlene Tabelle:
|
|
|
|
- `Notifications`
|
|
|
|
### 8.7 Monetization-System
|
|
|
|
Im MVP wird Monetization nur vorbereitet.
|
|
|
|
Das bedeutet:
|
|
|
|
- Soft Currency / Wallet-Struktur wird angelegt
|
|
- Katalog und Kaufhistorie koennen spaeter erweitert werden
|
|
- noch kein voller Store im ersten Release
|
|
|
|
Empfohlene Tabellen:
|
|
|
|
- `Wallets`
|
|
- spaeter `CatalogItems`
|
|
- spaeter `Purchases`
|
|
- spaeter `InventoryItems`
|
|
|
|
## 9. Kommunikationsarten
|
|
|
|
### 9.1 REST / HTTP
|
|
|
|
Wird fuer normale fachliche Operationen verwendet, die kein permanentes Live-Streaming brauchen.
|
|
|
|
Beispiele:
|
|
|
|
- Registrierung
|
|
- Login
|
|
- Freundesliste laden
|
|
- Lobby erstellen
|
|
- Profil laden
|
|
- Settings speichern
|
|
|
|
### 9.2 SignalR
|
|
|
|
Wird fuer Echtzeitkommunikation verwendet.
|
|
|
|
Beispiele:
|
|
|
|
- Poker-Zuege
|
|
- Lobby-Updates
|
|
- Online-Status
|
|
- Notifications
|
|
|
|
## 10. Warum trotzdem HTTP/REST auch bei einer Desktop-App?
|
|
|
|
Eine Desktop-App braucht kein Web-Frontend, kann aber trotzdem mit einem Server ueber HTTP sprechen.
|
|
|
|
Wichtig:
|
|
|
|
- `POST` und `GET` haben nichts mit Web-App oder Browser zu tun
|
|
- sie werden nur dann gebraucht, wenn der Client mit einem Server kommuniziert
|
|
|
|
In diesem Projekt ist das sinnvoll fuer:
|
|
|
|
- Registrierung
|
|
- Login
|
|
- Daten laden
|
|
- einfache CRUD-Vorgaenge
|
|
|
|
SignalR ist zusaetzlich fuer Live-Kommunikation da.
|
|
|
|
## 11. ADO.NET Repository-Schicht
|
|
|
|
Die Datenbankzugriffe werden explizit mit `ADO.NET` umgesetzt.
|
|
|
|
Verwendete Klassen:
|
|
|
|
- `SqlConnection`
|
|
- `SqlCommand`
|
|
- `SqlDataReader`
|
|
- `SqlTransaction`
|
|
|
|
Wichtige Prinzipien:
|
|
|
|
- nur parametrisierte SQL-Statements
|
|
- keine Business-Logik in Repository-Klassen
|
|
- jede komplexe Spielaenderung in einer Transaktion
|
|
- Mapper trennen SQL-Daten von Domain-Objekten
|
|
|
|
Beispielhafte Klassen:
|
|
|
|
- `SqlConnectionFactory`
|
|
- `UserRepository`
|
|
- `SessionRepository`
|
|
- `FriendshipRepository`
|
|
- `LobbyRepository`
|
|
- `HandRepository`
|
|
- `NotificationRepository`
|
|
- `WalletRepository`
|
|
|
|
## 12. SignalR-Hubs
|
|
|
|
### `PokerHub`
|
|
|
|
Zustaendig fuer:
|
|
|
|
- Tischstatus senden
|
|
- Aktionen empfangen
|
|
- Spiel-Updates broadcasten
|
|
|
|
### `LobbyHub`
|
|
|
|
Zustaendig fuer:
|
|
|
|
- Lobby-Status
|
|
- Beitritt / Austritt
|
|
- Einladungen
|
|
- Spielstart
|
|
|
|
### `NotificationHub`
|
|
|
|
Zustaendig fuer:
|
|
|
|
- persoenliche Benutzer-Benachrichtigungen
|
|
|
|
## 13. SQL-Server-Datenmodell
|
|
|
|
### Pflichttabellen
|
|
|
|
- `Users`
|
|
- `UserSessions`
|
|
- `FriendRequests`
|
|
- `Friendships`
|
|
- `Lobbies`
|
|
- `LobbyMembers`
|
|
- `LobbyInvites`
|
|
- `Tables`
|
|
- `Hands`
|
|
- `HandPlayers`
|
|
- `HandActions`
|
|
- `Notifications`
|
|
- `Wallets`
|
|
- `AppLogs`
|
|
|
|
### Wichtige SQL-Regeln
|
|
|
|
- IDs als `BIGINT`
|
|
- Geld- und Chipwerte als `INT`
|
|
- Zeitstempel als `DATETIME2`
|
|
- Indizes auf haeufig gesuchte Felder
|
|
- Poker-Aktionen immer in `SqlTransaction`
|
|
|
|
## 14. Sicherheitsprinzipien
|
|
|
|
- Passwort nie im Klartext speichern
|
|
- Hashing mit sicherem Verfahren wie `PBKDF2` oder `BCrypt`
|
|
- keine DB-Credentials im Client hart codieren
|
|
- keine kritischen Spielregeln im Client erzwingen
|
|
- jede Spieleraktion serverseitig validieren
|
|
- Sessions zeitlich begrenzen
|
|
- Logging fuer sicherheitsrelevante Aktionen
|
|
|
|
## 15. Erweiterbarkeit fuer spaetere Features
|
|
|
|
Die Architektur wird so vorbereitet, dass diese Features spaeter sauber ergaenzt werden koennen:
|
|
|
|
- Ranking-System
|
|
- Mini-Chat
|
|
- App-Settings
|
|
- Matchmaking
|
|
- Advanced Profile
|
|
- Store
|
|
|
|
Dafuer werden Datenmodell und Service-Grenzen so definiert, dass spaetere Erweiterungen nicht zu einem kompletten Umbau fuehren.
|
|
|
|
## 16. Empfohlene Entwicklungsreihenfolge
|
|
|
|
### Phase 1
|
|
|
|
- Solution aufsetzen
|
|
- SQL-Schema anlegen
|
|
- ADO.NET Basis
|
|
- Benutzer und Sessions
|
|
|
|
### Phase 2
|
|
|
|
- Registrierung und Login
|
|
- Logging-Basis
|
|
- Friendship Requests
|
|
|
|
### Phase 3
|
|
|
|
- private Lobby
|
|
- Lobby-Invites
|
|
- Notification-System
|
|
|
|
### Phase 4
|
|
|
|
- Poker-Spielregeln
|
|
- Hand- und Aktionspersistenz
|
|
- PokerHub
|
|
|
|
### Phase 5
|
|
|
|
- Wallet-Basis
|
|
- vorbereitete Monetization-Struktur
|
|
|
|
### Phase 6
|
|
|
|
- Nice-to-have-Features vorbereiten oder schrittweise umsetzen
|
|
|
|
## 17. Kurzfazit
|
|
|
|
Die empfohlene Architektur fuer dieses Projekt lautet:
|
|
|
|
- `WPF` fuer den Client
|
|
- `ASP.NET Core + SignalR` fuer den Serverprozess
|
|
- `ADO.NET` fuer die Datenbankzugriffe
|
|
- `SQL Server` fuer dauerhafte Speicherung
|
|
|
|
Damit bekommst du:
|
|
|
|
- klare Trennung von UI, Logik und Daten
|
|
- saubere Grundlage fuer Online-Multiplayer
|
|
- gute Erweiterbarkeit
|
|
- Kontrolle ueber SQL und Datenfluss
|
|
|
|
Diese Architektur ist fuer dein Projekt deutlich sinnvoller als ein reiner Direktzugriff des WPF-Clients auf die Datenbank, weil Social-, Lobby-, Notification- und Poker-Logik zentral und sicherer gesteuert werden koennen.
|