Verständnisfrage

[roNn]

Hallo zusammen =)

Ich schreibe gerade einen Onlineshop. Ein bisschen was ist dabei auch in OOP geschrieben worden. Z.B. habe ich eine Klasse Order, welche sich um die Bestellungen kümmert. Im Konstruktor verbindet sich die Klasse, mit Angabe der Bestell-ID, mit der Datenbank. Dann frage ich sie einzelnen Spalten ab, mit z.B. so einer Methode:

public function getStatus()
{
    return $this->dbArray['status'];
} 

Ich frage mich einfach ob das der richtige Weg ist, oder ob ich hier OOP vergewaltige!?
Weiterhin benutze ich die Klasse zum Beispiel zum Ausgeben von Content, denn dann brauche ich nur noch die Klasse anwerfen und $klasse->showBestellUebersicht schreiben.

Jetzt wollte ich eine Klasse für jede Tabelle der Datenbank schreiben. Also z.B. eine Klasse namens Kunde. Und ich frage mich jetzt, macht das Sinn? Oder sollte ich das lieber prozedural Programmieren und aus meinen "Methoden" simple Funktionen machen?

[sypr0]

Objekt orientiert zu programmieren ist immer sinnvoll bei einem solchen Vorhaben, ansonsten kannst du mal nach Vorteilen der OOP googeln.

Jetzt wollte ich eine Klasse für jede Tabelle der Datenbank schreiben. Also z.B. eine Klasse namens Kunde. Und ich frage mich jetzt, macht das Sinn? Oder sollte ich das lieber prozedural Programmieren und aus meinen "Methoden" simple Funktionen machen?

Es macht Sinn für jede Tabelle der DB eine Klasse zu erstellen, an der Stelle kann ich dir den phpobjectgenerator empfehlen (www.phpobjectgenerator.com), mit dem du die KLassen automatisch erstellen lassen kannst und der die gleichzeitig deine Web Anwendung in mehrere Schichten aufteilt (Anwendungebene - Datenbankebene..)

gruß

[Cologne]

Original geschrieben von sypr0

Es macht Sinn für jede Tabelle der DB eine Klasse zu erstellen

Da würde mich jetzt aber mal brennend interessieren, wie du darauf kommst, dass das Sinn macht.

[sypr0]

weil ich nichts finde was dagegen spricht :-).

Pros.: Einheitlichkeit bei der Programmierung, alle Vorzüge der OOP (Kapselung der Datenstrukturen, Wiederverwendbarkeit, Ermöglichung Anwendungen einfach in System- und Anwendungsteile zu kapseln...),..


Kontras: Bisschen mehr Programmierarbeit, die sich aber auszahlen könnte und die ich in Kauf nehm. Wobei dieser Mehraufwand duch Mappingtools stark verringert wird

[Cologne]

Vorteile von OOP musst du mir jetzt nicht erklären, ich dachte jetzt eigentlich eher an Argumente die dafür sprechen, für jede Datenbank-Tabelle eine eigene Klasse zu schreiben.
Das klingt für mich nämlich etwas unsinnig

[PHP-Desaster]

Was du da beschreibst, ist unter anderem auch als ActiveRecord-Pattern oder ORM bekannt. Für PHP ist Doctrine da zum Beispiel gar nicht verkehrt.

[sypr0]

warum soll es bei der o.g. Sachlage (Online Shop) unsinnig sein für jede Tabelle eine Klasse zu erstellen?

[combie]

Jedem Datenmodell (aus MVC) eine Klasse zu spendiern ist korrekt! Aber manchmal brauchts dafür eben mehere Tabellen. Wäre doof, das unnötig zu zersplittern.

[roNn]

Sehr interessante Diskussion!
Also ist es richtig eine Klasse (für das Beispiel Onlineshop) für jede oder sagen wir für wichtige Tabellen zu erstellen. Z.B. eine Klasse für Kunden welche über die KundenID die Daten aus der DB zu einem Objekt formt? Und dann eine Datenbank für die Bestellungen, welche über eben diese ID ein Objekt bildet? Dann noch eine Klasse für die Artikel zum Beispiel.
Aber eine Klasse für die Rubriken wäre dann zuviel des Guten..

Soweit richtig?

Dann würde mich noch interessieren ob folgende Lösung "richtig" ist:

Ich habe die Klasse für die Bestellungen und über diese greife ich dann auf die Kundenklasse mit folgender Methode zu:

public function getCustomerObject()
{
    $customer = new Customer($this->getKundenID());
    return $customer;
} 

Schliesslich kann ich dann über das bereits erzeugte Bestellungsobjekt auf die Daten der Kundenklasse zugreifen:

$order = new Order($row->ID);    
$kunde = $order->getCustomerObject();
echo $kunde->getFullName(); 

Oder ist das Blödsinn und ich sollte mir Gedanken über eine Vererbungshierarchie machen?

[Cologne]

MVC, natürlich, da ist es sinnvoll, je Tabelle auch in einem einzelnen Modell zu verarbeiten, aber die eigentlichen Controller, also die Hauptlogik, die würde ich nicht nach Datenbanktabellen sondern nach Zusammenhängen sortieren.
Nicht alles was du machen willst, geschieht immer nur über einen Tabelle.
Manchmal musst du vielleicht joinen oder du brauchst Daten aus verschiedenen Tabellen, wie z.B. die Kundendaten, die Rechnungsdaten und zusätzlich die Bestelldaten oder so...
Das sind mindestens drei unterschiedliche Tabellen, die du alle in einem Controller brauchen wirst.
Da siehst du also schon, das die strikte Trennung nach Tabellen a) gar nicht möglich ist und b) oft auch nicht sinnig.

Ich lege Klassen (Controller) nach ihren Aufgaben zusammen.
Da gibt es dann die Klasse "Registrierung" beispielsweise, die sich um alles was mit der Registrierung zu tun hat kümmert, eine Klasse "Bestellung", eine Klasse "Abrechnung" und eine Klasse "Kunden".
Die greifen teilweise alle auf die gleichen Datenbanktabellen zu, machen aber vollkommen unterschiedliche Sachen mit diesen Daten.
Ich denke, nach "Themen/Aufgaben" sortiert wird dir am Ende helfen, den Überblick nicht zu verlieren.

Und für ganz bestimmte Dinge, die ich sehr oft benötige, lege ich mir zusätzliche "Helper-Klassen" an, wo so Sachen wie z.B. im UserHelper dann "getUserNameByUserId()" oder "saveUserData()".
Das sind Sachen, die mit der Programmlogik ansich nicht viel zu tun haben, deswegen hab ich sie nicht mit in der Hauptklasse "User", sondern lasse sie in einem "UserHelper" verschwinden, den ich bei Bedarf als Singleton einfügen kann.

Aber letztlich entwickelt da auch jeder irgendwie seine eigenen Strategien.
Wichtig ist, dass du dich am Ende mit der Struktur wohl fühlst und damit zurecht kommst.

[unset]

Wobei der Controller keine Ahnung von Tabellen hat. Der Controller arbeitet mit den Modellklassen, diese wiederum greifen auf Tabellen zu. Generell wurde auch gesagt, das es durchaus Sinn macht, für jede Tabelle eine eigene Klasse zu schreiben. Zwangsläufig brauchst du für Verknüpfungstabellen ebenfalls eigene Klassen. Dass du das abstrahieren kannst und die Implementierten Klassen dann durchaus so klein sein können, als dass in ihnen nur noch gesagt wird, mit welcher Tabelle sie Arbeiten und evtl. ein oder zwei kleine Minimethoden haben, ist natürlich klar.