poker-texas-holdem/Poker-texas-holdem.md

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

WPF UI
-> ViewModel
-> Client Service
-> SignalR / HTTP

Server-Seite

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.