# 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.