Dateien nach "/" hochladen
This commit is contained in:
@@ -0,0 +1,551 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user