Du bist nicht angemeldet.

Werbeanzeige

Stazer

Alter Hase

  • »Stazer« ist der Autor dieses Themas

Beiträge: 468

Wohnort: Berlin

Beruf: Student

  • Private Nachricht senden

1

12.12.2013, 20:31

SQL Datenbank und Klassen Frage

Moin,
mometan programmier ich ein kleines Browsergame in PHP und nun, da alles durch Einheiten etwas komplexer wird, tauchen einige Fragen bezüglich des Designs der Datenbank und der Klassen auf. Mal angenommen ich habe eine Tabelle Namens 'Objects'. Diese speichert in verschiedene Spalten die Daten eines Objekts. Für diese Tabelle existiert eine Klasse, welche 'Object' heißt und ein Objekt darstellt.

Ist es ratsam mit dem Konstruktor die Daten aus der Tabelle zu lesen, in der Klasse zu speichern und mit dem Destruktor diese bei Veränderung in die Tabelle zu schreiben?
Wie wird professionell die Handhabung der Daten zwischen Klassen und Datenbank gelöst?

Freundliche Grüße
Stazer

Sacaldur

Community-Fossil

Beiträge: 2 320

Wohnort: Berlin

Beruf: FIAE

  • Private Nachricht senden

2

12.12.2013, 21:43

Es wurde ja schon geschrieben, dass die Klassen, deren Objekte am Ende die Daten beinhalten, nicht den Code für den Datenbankzugriff beinhalten, da dieser dort auch absolut nicht hingehört.

In dem Zusammenhang fallen mir die Begriffe "objektrelationales Mapping" und "objektrelationale Datenbank" und "Data Access Object" ein. Grob formuliert befassen sich das erste mit der Übersetzung von Objekten in Daten für ein relationales DBMS, während letzteres allgemein eine Schnittstelle zu irgendeiner Art der Persistierung bzw. das Laden (Datenbank, lokale XML/CSV/YAML/JSON/... Dateien, Webservicezugriffe, ...).
Spieleentwickler in Berlin? (Thema in diesem Forum)
---
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].

Stazer

Alter Hase

  • »Stazer« ist der Autor dieses Themas

Beiträge: 468

Wohnort: Berlin

Beruf: Student

  • Private Nachricht senden

3

12.12.2013, 22:42

Ich habe ja oben bereits geschrieben, dass ich als nächstes vorhabe Einheiten zu implementieren, deshalb ist es mir in den Sinn gekommen, ob nicht der Ansatz gut wäre die Daten im Konstruktor zu laden und im Destruktor zu schreiben. Die SQL Abfragen würden mit Hilfe einer Klasse für Datenbank , Tabelle und Eintrag auch nicht direkt in den Methoden gemacht werden. Momentan ists so gelöst, dass ich die Daten separat aus der Datenbank von der Klasse laden kann bzw. die Daten in der Klasse in die Datenbank schreiben kann.

Wenn ich ehrlich bin, finde ich es ein wenig Mühselig.
Was spricht denn dagegen, dass man die SQL Abfragen direkt ( oder halt indirekt durch Klassen für Datenbank, Tabellen und Einträge ) in den Methoden macht?

Freundliche Grüße
Stazer

Sacaldur

Community-Fossil

Beiträge: 2 320

Wohnort: Berlin

Beruf: FIAE

  • Private Nachricht senden

4

12.12.2013, 22:54

Die Art und Weise, wie die Daten gespeichert oder geladen wird, sollte nicht durch die Klasse bestimmt werden, die diese am Ende "nur beinhaltet".
Es ist zwar durchaus möglich, so vorzugehen und wenn du das so machen willst, dann kannst du es durchaus so machen, nur werden dir die meisten Leute sagen, dass das nicht besonders sauber ist.
Abgesehen von der Art der Trennung: man kann ein einzelnes Objekt anhand seiner ID laden, aber was macht man, wenn man eine ganze Liste an Objekten (/eine Menge von Objekten) mit einem Mal laden will, ohne dass man vorher deren ID kennt? (bspw. alle Planeten eines Spielers, alle Planeten eines Spielers in Sektor Xyz, alle Spieler mit einem Planeten in Sektor Xyz, ...). Ein Konstruktoraufruf hilft da nicht weiter, also würde man wohl eine statische Methode an der jeweiligen Klasse haben, die diese auslesen kann.
Wenn der Code für die Abfrage aus der Datenbank dann nicht in den Objekten selbst liegt: wie kommt der Konstruktor an eine entsprechende Instanz? (Oder sollte es ein Singleton sein bzw. nur statische Methoden?) Wie werden die Daten dann zurückgegeben? Ein entsprechendes Objekt zu erzeugen geht ja nicht, da man dann gleich von anderer Stelle genau diese Methode aufrufen könnte, ohne den Umweg über den Konstruktor.
(Und das sind nur die Probleme, die mir auf Anhieb eingefallen sind...)
Spieleentwickler in Berlin? (Thema in diesem Forum)
---
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].

Stazer

Alter Hase

  • »Stazer« ist der Autor dieses Themas

Beiträge: 468

Wohnort: Berlin

Beruf: Student

  • Private Nachricht senden

5

12.12.2013, 23:08

Die Art und Weise, wie die Daten gespeichert oder geladen wird, sollte nicht durch die Klasse bestimmt werden, die diese am Ende "nur beinhaltet".
Es ist zwar durchaus möglich, so vorzugehen und wenn du das so machen willst, dann kannst du es durchaus so machen, nur werden dir die meisten Leute sagen, dass das nicht besonders sauber ist.
Abgesehen von der Art der Trennung: man kann ein einzelnes Objekt anhand seiner ID laden, aber was macht man, wenn man eine ganze Liste an Objekten (/eine Menge von Objekten) mit einem Mal laden will, ohne dass man vorher deren ID kennt? (bspw. alle Planeten eines Spielers, alle Planeten eines Spielers in Sektor Xyz, alle Spieler mit einem Planeten in Sektor Xyz, ...). Ein Konstruktoraufruf hilft da nicht weiter, also würde man wohl eine statische Methode an der jeweiligen Klasse haben, die diese auslesen kann.
Wenn der Code für die Abfrage aus der Datenbank dann nicht in den Objekten selbst liegt: wie kommt der Konstruktor an eine entsprechende Instanz? (Oder sollte es ein Singleton sein bzw. nur statische Methoden?) Wie werden die Daten dann zurückgegeben? Ein entsprechendes Objekt zu erzeugen geht ja nicht, da man dann gleich von anderer Stelle genau diese Methode aufrufen könnte, ohne den Umweg über den Konstruktor.
(Und das sind nur die Probleme, die mir auf Anhieb eingefallen sind...)

Stimmt, an sowas hab ich garnicht gedacht. Jetzt leuchtet es mir auch ein, dass mit den Konstruktoren und Destruktoren sein zu lassen und lieber so vorzugehen wie bisher.
Vielen lieben Dank!

Freundliche Grüße
Stazer

BlueCobold

Community-Fossil

Beiträge: 10 874

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

6

13.12.2013, 07:26

Ein Dekonstruktor ist irgendein Ding in WoW.
Ein Destruktor ist das Teil, was am Ende des Lebenszyklus eines OOP-Objekts aufgerufen wird.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

BlueCobold

Community-Fossil

Beiträge: 10 874

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

7

13.12.2013, 15:22

Dabei ist es doch ganz einfach:
to destruct - zerstören - destruction - Zerstörung
to construct - erstellen - construction - Erstellung

Das englische Wort für "Zerstörung" sollte doch jeder Gamer kennen.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Stazer

Alter Hase

  • »Stazer« ist der Autor dieses Themas

Beiträge: 468

Wohnort: Berlin

Beruf: Student

  • Private Nachricht senden

8

13.12.2013, 16:57

Die Datenbankverbindung hätte ich natürlich persistent gehalten, aber Sacaldurs Beispiel hat mir ein paar Probleme schon aufgezeigt, weshalb ich das mit den Konstruktoren und Destruktoren lieber lassen sollte.

Freundliche Grüße
Stazer

Werbeanzeige