King joe schrieb:
Im allgemeinen möchte ich das problem objektorientiert lösen.
Dann solltest Du imho die gängigen objektorientierten Prinzipien und ggf. dazu anerkannte Design Pattern nutzen.
Im speziellen habe ich bis jetzt folgende Möglichkeit angegangen: Ich habe eine Klasse die als Eigenschaft ein Array besitzt, welches im Konstruktur mit allen Daten aus der MySql Tabelle gefüllt wird. Es hat folgende Struktur:
array[ROWx] = array(column1=>WERTx1,column2=>WERTx2,columnn=>WERTxn)
Jetzt hat die Klasse verschiedene Methoden zum bearbeiten des Arrays und eine Methode zum speichern des Arrays in der Datenbank wobei alle alten Einträge überschrieben werden.
Zusammengefasst:
<*> Alle Daten aus der Tabelle in einem Objekt->Array gespeichert
<*> Bearbeitung des Arrays durch Objekt->Methoden
<*> Array wieder in Datenbankstruktur übertragen und speichern
Ist dieses Vorgehen sinnvoll?
Auch wenn ich aus dem Beitrag nicht alles verstanden habe, so schwant mir dabei nichts gutes.
Du vermischst imho zu sehr die Domänenschicht mit der Datenzugriffsschicht. Dies ist per se suboptimal, da Du damit automatisch mehrere OO-Prinzipien verletzt und dies immer ein Indiz dafür ist, dass man einen schlechten Ansatz gewählt hat.
Was auch immer Du in der DB stehen hast, sind ja lediglich Daten. In einer Welt von Objekten denkst Du aber nicht in Daten, sondern eben in Objekten, die eine bestimmte Aufgabe haben und ein spezielles Konzept Deiner Problem-Domäne abbilden. *Wie* diese Objekte mit Inhalt gefüllt werden, gehört *nicht* in das Objekt selber hinein! In vielen Fällen stammen Attributwerte tatsächlich aus einer relationalen Datenbank, es können aber ebenso gut Werte aus Benutzereingaben, XML- oder JSON-Nachrichten von Webservices oder last but not least Testdaten für Unit- / Intergrationstests sein.
Ich würde annehmen, dass Dir noch nicht klar ist, wie Deine Domänenobjekte aussehen, wie sie interagieren und zusammen gehören. Wenn Du diese Objekte modellierst, denke stets daran, dass die *vollständig* unabhängig von irgend einer Datenzugriffstechnologie sein sollten!
Das Manipulieren von Attributen von solchen Objekten sollte *nur* auf Domänenebene
geschehen!
Wenn Du ein Objektmodell der Domäne hast, dann kannst Du Dich an die Datenzugriffsschicht machen und sogenannte Data Access Objekte (DAOs) implementieren. Diese können sich dann darum kümmern, wie ein Objekt tatsächlich in die Datenbank reinkommt, rauskommt, in der DB verändert werden muss usw. Sprich das typische CRUD eben.
Merke: Die DAOs kennen die Domänen-Objekte, nicht aber anders herum!
In einem DAO könntest Du also eine Methode anbieten, die ein einzelnes Objekt in die DB schreibt. Dies kann simpel über insert passieren. Wenn Du das DAO "schlau" machst, kann es daürber hinaus selber entscheiden, ob das Objekt "neu" ist (→ insert) oder nur verändert ist (→ update). Dazu kannst Du eine Methode anbieten, die eine Sammlung (z.B. ein Array) von Domänen-Objekten in die DB schreibt... dafür kann das DAO dann ggf. einen Bulk-Insert Mechanismus nutzen, was bei großen Datenvolumen einen großen Zeitvorteil mit sich bringen kann. Wie Du siehst, kannst Du solche Optimierungen dann auf der unteren Ebene anbringen - Deinen Domänen-Objekten kann und sollte das vollkommen egal sein!
Ich könnte dazu noch zig Seiten an Sermon schreiben, aber ohne genauere Angaben oder Feedback von Dir, geht das dann vermutlich ins leere... 😉
Wichtig als Quintessenz ist das eine: Persistenzmechanismen aller Art gehören nicht zu einem Domänen-Objekt! (Selbiges gilt ebenso für andere Dinge wie GUI-Repräsentation, Benutzer-Eingaben und alle anderen "Cross Concern"-Aspekte)
SRP ist das einfachste OO-Prinzip und sollte immer befolgt werden.
Du könntest Dir übrigens überlegen, eine Bibliothek zu nutzen, die dafür gemacht ist. Sogenannte "Objekt relationale Mapper" (ORM) sind genau das, was Du suchst. Die gibt es auch für PHP. Mit ein wenig Glück bieten die auch einen "SQL Abstraction Layer", der dynamische Queries ermöglicht, ohne sich SQL per Hand zusammen zu frickeln.
In den Methoden alle Werte einzeln durch Mysql-Querys zu bearbeiten ist durch die doch recht große Menge an Werten nicht so sinnvoll,oder?
Definitiv ja! Auf der Datenzugriffsseite kannst und solltest Du DB-Zugriffe optimieren; durchaus sogar speziell für das zugrunde liegende DBMS. Das schließt ein, dass man nicht bei jeder Änderung an einem Objekt-Attribut gleich ein update auf die DB los lässt.
