Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Meine bisherige Überlegung dazu sieht folgendermaßen aus: Pro Tabelle in der Datenbank existiert eine Klasse, deren Attribute die einzelnen Spalten der Tabelle darstellen und diese mittels get/set Methoden zur Verfügung stellen. Einzelne Objekte dieser Klasse repräsentieren somit die verschiedenen Zeilen. Mittels unterschiedlicher statischer get-Methoden in der Klasse können verschiedene SQL-Queries ausgeführt werden (zB getAllByID() getAll() getAllByName() etc.). Nicht-statisch hingegen sind save()- und delete()-Methoden, mit welchen einzelne Objekte gelöscht bzw. gespeichert werden können.
Allgemein entsprechen diese Klassen somit nur einem Daten-Container, der ein wenig Logik implementiert. Die eigentliche Logik des Spiels wird separat dazu umgesetzt, hier will ich lediglich auf die DB-Kommunikation hinaus.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »dot« (26.12.2015, 21:47)
Also ich halte dein Design für "gefärlich"...
Es kann zu Inkonsistenzen zwischen den Daten in der Datenbank un deinen Datenklassen kommen, es sei denn deine Datenklassen schreiben alle Änderungen automatisch in die Datenbank.
Oder ist diese "Inkosistenz" gewollt?
Ja, so ein Design sieht man recht häufig. Meine Erfahrung mit Datenbanken hält sich in Grenzen (ich darf mich allerdings regelmäßig mit einer Website, die auf praktisch exakt einem solchen Design in PHP aufbaut, rumschlagen und kann es gar nicht mehr erwarten, bis das Ding endlich weggeworfen und neu geschrieben wurde), aber ich persönlich würde versuchen, die Abstraktion etwas höher anzusetzen. Das von dir vorgeschlagene Design kapselt effektiv nur die SQL Abfragen; bereits das Datenbankschema an sich leaked in einem solchen Interface so halb heraus. Ich würde versuchen, die Abstraktion so hoch anzusetzen, dass selbst die Tatsache, dass im Hintergrund eine Datenbank steht, gänzlich zu einem Implementierungsdetail wird. Insbesondere das mit den statischen Methoden würd ich mir schonmal schwer überlegen. (Wieso überhaupt erst eine Klasse, wenn es effektiv nur ein paar Funktionen geben soll, die auf globalem Zustand arbeiten? Wenn es eine globale Datenbank geben soll, wäre es nicht besser, einfach ein globales Objekt mit entsprechenden Methoden zu haben?) Überleg dir mal, wofür genau die Datenbank verwendet werden soll. Musst du wirklich alle Arten von Objekten per Name oder ID oder was auch immer abfragen können? Wie sieht denn die Anwendungslogik aus, die auf dieser Datenbank errichtet werden soll? Geht es im Endeffekt nicht vielleicht sogar mehr einfach nur um Serialisierung/Deserialisierung!?
C-/C++-Quelltext |
|
1 2 3 4 5 6 7 8 9 10 |
class DummyRow { public: unsigned int getID(); void setID(unsigned int id); ... static smart_ptr<DummyRow> getByID(unsigned int id); //Lädt ein Objekt static vector<smart_ptr<DummyRow> > getAll(); //Lädt alle Objekte aus der Tabelle private: unsigned int mID; }; |
Für ein früheres Projekt haben wir genau so einen Ansatz gewählt. Bei uns war die Datenbank aber auch "nur" eine reine Backup Lösung. Dafür funktioniert es aber recht gut. Inkonsistenzen können zwar entstehen, aber SQL kann dabei dabei helfen Fehlerquellen zu vermeiden (ID Überprüfungen).
Zwar ein wenig Offtopic aber:
Schau doch mal in die diversen Projekte, die "Alternativserver" für überaus populäre RPGs bieten. Das sind zwar keine Browserspiele, aber arbeiten serverseitig mit einer Datenbank und C++ Logik. Vielleicht findest du da einige Inspirationen/Alternativansätze. Und da ich schon ein wenig im Off bin ein paar Stichworte für mögliche Implementierungswege (falls du dich da noch nicht festgelegt haben solltest): mysql++, MySQL’s Connector/C++, postgreSQL, libpqxx, libpq++.
Und libpqxx ist nichts für dich? Zu der anderen Frage: Ich habe mich selbst noch nicht damit intensiv beschäftigt, aber vllt sind ArcEmu und MangosZERO für dich interessant.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Werbeanzeige