[Ben]

Hallo,
ich lese mich gerade etwas in propel ein.

In diesem Thread gab es ja schon eine kleine Diskussion zu der Art, wie man die Datenbankabstraktion vornimmt bzw. vornehmen kann bzw. Daten speichert etc. .. blubb. Darauf hin habe ich mir auch mal wieder ein paar Gedanken gemacht.

Ich habe nun etwas herumgelesen. propel, ezpdo ... oder doch selbst machen?

Im Gemeinschafsprojekt des Developer's Guide hatten wir vor das Model selbst eigenhändisch zu schreiben. Nun sind wir uns aber nicht mehr ganz sicher, ob das der richtige Weg ist oder ob man nicht doch besser auf ein fertiges "Framework" zurückgreifen sollte. Ganz einfach deshalb, weil fertige Systeme à la propel doch schon recht gut sind, wenn man das so grob sagen kann/darf.

Der Code folgt dem "MVC"-Prinzip .. sofern das in PHP eben möglich ist. Nun ist propel ja standardmäßig "nur" mit Adaptern für unterschiedliche Datenbanksysteme ausgestattet. Es müssten also Adapter für Dateien hinzugefügt werden.
Und hier stellt sich dann eben das Problem ... wie macht man das und .. geht das überhaupt? Ohne Weiteres muss nicht sein. Man will ja dazu lernen, so dass man sicherlich auch dazu bereit ist, propel intensiv zu studieren, damit man es um diese Adapter erweitern kann.

Frage ist nun einfach.
Kennt jemand eventuell Alternativen zu dieser Herangehensweise bzw. verlauf ich mich gerade mit meinen Gedanken in eine Sackgasse?

Sollte man propel einfach für die Arbeit mit RDBMS nutzen und sozusagen in das "eigene Model" integrieren, so dass man letztlich dann die selben Zugriffswege auf Dateien, wie auf Datenbanken hat?

Bin gespannt auf Meinungen, Ideen etc.

Grüße,Ben.

[PS]
Ich habs mal in dieses Forum gepostet, weil es ja schon um fertige Sachen geht (propel), auch wenn eher eine allgemeine Diskussion zu diesem Thema angeregt wird.

[Basti]

Hi.

Ich denke, am einfachsten wäre da vielleicht, einen Wrapper um Pdo zu legen und eben einen Treiber in PHP zu ergänzen. Weiß allerdings nicht auf Anhieb,
ob es wirklich so sinnig ist, da du Dateen ja in der Regel nicht mir Queries ansprichst etc.

Vielleicht taugt auch das DB-Modul des ZendFramework, um dieses entsprechend zu erweitern.


Ich bin gerade dabei, das zu Fuß umzusetzen und bin auch gerne berit, den Code z.B. unter der GPL zu veröffentlichen und gemeinsam dran zu arbeiten.


Kann da allerdings grad nicht viel ausdiskuieren, weil es erstmal
gerade so laufen muss - es vorher zu veröffentlich ist wohl sicher auch nicht sehr sinnig.

Hier mal Entwurf (bis jetzt...)
http://fallingarms.de/linked_images/persistence.png

//edit:
Ich werde das TanserObject nicht als Iterator implementieren, da ich sonst (um rewind() implementieren zu können) ja alle ausgelesenen Datensätze dort nochmal speichern müsste und das Objekt ja nur einml ausgelesen werden muss, um ein DataObject oder alle DataObjects in einer DataObjectList zu erzeugen. Es wird also erstmal nur die Methoden fetch([classname]) und numRows() oder so geben.

Basti

[Ben]

Zitat von Basti

Ich denke, am einfachsten wäre da vielleicht, einen Wrapper um Pdo zu legen und eben einen Treiber in PHP zu ergänzen.

Jap, da hatte ich heute morgen auch drüber nachgedacht.

Zitat von Basti

ob es wirklich so sinnig ist, da du Dateen ja in der Regel nicht mir Queries ansprichst etc.

Sofern man eine Struktur hat, wie z.B. in XML-Dateien, hat, also mit "Namensräumen" oder nennen wir es gröber "Kategorien", sollte das aber auch mit etwas Trickserei möglich sein.

Letztlich entscheidet ja die "Adapterklasse" wie die Daten ausgewertet bzw. verwertet werden müssen/sollen.

Beispiel:

PHP-Code:

$dataset = $model->getDataset($tables, $columns, ...); 


Nur mal so grob. (Ist mir bewusst, dass das nu nicht die optimale Lösung ist!)

Was dann da intern passiert kann mir ja egal sein.
Das $tables wäre dann im Prinzip sowas wie eine Struktur. Dabei ist es ja egal, wo diese Struktur liegt. Ist ja bei propel ähnlich. Da liegen die Datenbankstrukturen auch in XML-Dateien.

Zitat von Basti

Ich bin gerade dabei, das zu Fuß umzusetzen und bin auch gerne berit, den Code z.B. unter der GPL zu veröffentlichen und gemeinsam dran zu arbeiten.
[..]
Hier mal Entwurf (bis jetzt...)
http://fallingarms.de/linked_images/persistence.png

Hört sich aber definitiv interessant an!

Grüße, Ben.

[Basti]

Die Frage ist halt, ob es sich lohnt, Pdo und den Zugriff auf Dateien zusammenzupacken.

Wenn es um XML-Dateien geht, bist du bestimmt flexibler, wenn du daraus einen DOM-Baum machst, wenn es sich um CSV-Daten handelt, ist das so sicher kein Problem - vorausgesetzt, die erse Zeile entspricht dann den Bezeichnern der Attribute.

Basti

[Ben]

Zitat von Basti

Die Frage ist halt, ob es sich lohnt, Pdo und den Zugriff auf Dateien zusammenzupacken.

Hm, sicherlich.

Die Situation stellt sich eben so dar, dass wir "ein Model" bauen möchten, welches dann eben den ganzen Persistenzkram übernimmt .. und nicht zig Klassen, eine für die Datenbankkommunikation, eine für einen XML-Baum etc., um etwas mehr Flexibilität hineinzubringen.
Kurz: Es sollte egal sein, wo die Daten herkommen.

Dazu Kommentare?

[Basti]

Im einfachsten Fall hast du für dein Modell Daos. Dort kapselst du dann die komplette Datenanbindung hinter sprechenden Methoden, wie ProductDao::getByCategory(). Die erstellst du durch eine DaoFactory. Damit hast du schonmal viel Unabhängigkeit erreicht, denn diese Daos kannst du später ja von bestimmten abstrakten Daos ableiten, denen die DaoFactory z.B. die benötigten Verbindungsdaten übergibt.

Ich kann eigentlich nicht mehr erzählen, als eben das, was im Entwurf oben zu sehen ist, da das eben grad mein aktueller Stand in dem Bereich ist.

Aber hier haben sicherlich noch andere Leute anregungen oder ganz andere Ansätze...

Basti

[Ben]

Zitat von Basti

Im einfachsten Fall hast du für dein Modell Daos. Dort kapselst du dann die komplette Datenanbindung hinter sprechenden Methoden, wie ProductDao::getByCategory(). Die erstellst du durch eine DaoFactory. Damit hast du schonmal viel Unabhängigkeit erreicht, denn diese Daos kannst du später ja von bestimmten abstrakten Daos ableiten, denen die DaoFactory z.B. die benötigten Verbindungsdaten übergibt.

Sorry, ich habs nun echt 'ne zeitlang versucht mir das an deinem UML-Diagramm verständlich zu machen. Klappt net.

Ich weiß nicht, was du meinst ...


[PS]
Ganz zu schweigen davon, dass wir ja kein Persistenz-Abstraktions-Framework entwickeln wollen, sondern einen Webshop.
Aus diesem Grund eben meine Frage: Wie kann man Bestehendes optimal eingliedern, falls nötig.

Hoffe mal, dass hier bald noch ein paar andere Leute was schreiben..nix gegen dich Basti.

[Byrel]

Hey!

@Ben
Bezgl. DAO
Sieh dir mal die SDO Erweiterung an (http://www.php.net/sdo, http://www.zend.com/pecl/tutorials/sdo.php)

Jetzt zur eigentlichen Frage:

Ich habe zwar schon ein paar Tutorials und Berichte über Propel gelesen, allerdings weiß ich nicht ob Propel skaliert bzw. wie es intern arbeitet.

Am einfachsten und besten aus Performance Sicht ist wahrscheinlich wenn man sich für jede Tabelle eine Klasse schreibt und Methoden zur Verfügung stellt um die Daten zu manipulieren.

z.B.

class Artikel {
   public function deleteArticle ($id)
   public function getXXXByXXX ()
   public function setSth ($arg1, array $arg2 ... )
   ...
}

Theoretisch interessant, aber praktisch ohne Sinn finde ich die Zend_Db_* Klassen des Zend Frameworks, die ja auch auf PDO aufsetzen. Außerdem machen die 27% der Bugs im "Issue Tracking System" von Zend aus und sind noch fast alle offen :>.

Aber ich bin halt auch kein Profi (Teenager halt :>).

Naja, vielleicht hat dir mein Beitrag ein bisschen geholfen.

MfG,
Byrel

[Ben]

Zitat von Byrel

Am einfachsten und besten aus Performance Sicht ist wahrscheinlich wenn man sich für jede Tabelle eine Klasse schreibt und Methoden zur Verfügung stellt um die Daten zu manipulieren.

ActiveRecordPattern halt, ne?

Joa, wollte ich heute noch was zu schreiben, wird dann aber wohl doch erst morgen hier reinkommen.
Trotzdem danke ..

Grüße, Ben.

[Basti]

Ne, Propel und auch das, was ich da mache setzen das ActiveRecord Pattern um. Dort wird jede Zeile in der Datenbank, also jeder Datensatz als Objekt repräsentiert, das nicht nur die Daten enthält, sondern auch die Funktionen, das Verhalten.

Bei dem oben genannten wird eben "nur" jede Tabelle als Ganzes durch ein Objekt repräsentiert. Das sind dann meiner Ausffassung nach die klassischen DAOs. Das was ich oben eben meinte mit der Kapselung der Datenbankzugriffe hinter Methoden mit "sprechenden Namen". Ist natürlich flotter, aber von der Handhabung natürlich nicht zu vergleichen.

...aber ich halt jetzt wieder meine Klappe *g ...fürs Erste.

Basti

[Byrel]

PHP-Code:

<?php

// may be implemented as an abstract class
class DataSet extends SplObjectStorage {

    
}

interface Model_IArticles {
    public function getByCat ($cat);
    public function addArticles (DataSet $ds);
    public function deleteArticle ($identifier);
}

class Model_Database_Articles implements Model_IArticles {
    
    public function getByCat ($cat) {
        
        // get data from Database
        
        return new DataSet ( ... );
    }
    
    public function addArticles (DataSet $ds) {
        
        foreach ($ds as $object) {
            // save    $object in db
        }
    }
    
    // ...
}

class Model_Xml_Articles implements Model_IArticles {
    
    public function getByCat ($cat) {
        
        // get data from xml
        return new DataSet ( ... );
    }
    
    public function addArticles (DataSet $ds) {
        
        foreach ($ds as $object) {
            // save $object in xml
        }
    }
    
    // ...
}

$modelArticles = new Model_Database_Articles ();

$articles = $modelArticles->getByCat ($cleaned["cat19"]);

// operate in controller with articles
for ($articles->rewind ();
     $articles->valid ();
     $articles->next ()) {
         echo $articles->current ();
     }

echo "There are " +  count ($articles) + " in this category";

?>

So in etwa finde ich das ganz praktisch (okay, Articles ist ein blödes Beispiel, aber da du ja einen Webshop programmierst)

Meiner Meinung nach ist es so ganz komfortabel und man muss sich nicht mit den kompliziertesten Sachen rumärgern. Design Patterns sind ja auch nur sicher funktionierende Denkweisen IMHO und kein Standard. Aber ich habe kaum Ahnung von Design Patterns (Observer, Singleton, Factory, Strategy, MVC, Compositor ...) und kann nix genaueres dazu sagen.

@Basti
Welche Vorteile hat man eigentlich wenn man DAOs verwendet. Ich habe mir nämlich dein Diagramm angesehen und eigentlich nix verstanden.

MfG
Byrel

[Basti]

Zitat von Byrel

Welche Vorteile hat man eigentlich wenn man DAOs verwendet.

Deine Klassen Model_Database_Articles und Model_Xml_Articles sind eigentlich schon DAOs. Aus der Sicht der Clients hast du nur Model_IArticles mit den definierten Methoden, die dir auch immer die DataSets zurückgeben, ganz gleich, ob da jetzt eine XML-Datei oder eine Datenbank dahinter liegt.

Das der größte Vorteil. Ich hab z.B. alle DAOs in einem Verzeichnis Dao. Sämtliche SQL-Queries befinden sich ausschließlich in diesem Ordner.

Ich habe mir nämlich dein Diagram

m angesehen und eigentlich nix verstanden.l

Hab ich mir in meinen autodidaktischen "Studien" einen so krassen UML-Slang beigebracht, denjetzt keiner außer mir lesen kann? Langsam komme ich ins Grübeln.

Meine Manager-Klassen entsprechen von der Funktionalität in etwa deinen Model-Klassen oben. Wobei diese Unabhängig von der verwendetn Datenquelle ist. Dafür hat jeder Manager ein datenquellenspezfisches Dao.

Von dem bekommt es ein TransferObject, das im Falle von MySQL praktisch die beiden Funktionen mysql_fetch_assoc() und mysql_num_rows() kapselt (und nicht mehr Iterator implementiet, wie es noch im Diagramm zu lesen ist). Die DataObjectManager geben nun aber nicht DataSets zurück, sondern entweder DataObjets, DataObjectLists oder ... mal sehen, was für Anfragen es alles geben wird.

Der DataObjectManager kennt alle seine DataObjects, jedes DataObject hat genau einen Manager und wird auch nur von diesem gebaut/verwaltet. Damit will ich es hinbekommen, dass eben jeder Datensatz nur maximal einmal repräsentiert ist.

DataObjects können auch unvollständig sein und werden erst bei Bedarf volständig nachgeladen.

Basti

[Byrel]

Danke für die Erklärung. Hat mir beim Verständnis weitergeholfen.

[Jojo]

Ich muss sagen, dass ich so langsam (und nach langem Lesen) ein wenig Einblick in die Techniken DAO von Byrel oder das ActiveRecordPattern von Basti bekomme...

Danke erstmal dafür!

Da meine bisherigen Programmierungarbeiten allerdings keine vergleichbaren Strukturen aufwiesen (MySQL-Objekt und gut ) und mir auch just keine tolle Lösung einfällt, werde ich wohl meine Meinung für oder gegen eins der beiden vorgestellten Modelle aussprechen.

Propel oder etwas vergleichbares ist in meinen Augen recht praktisch und auch angenehm zu benutzen. Allerdings muss ich sagen, dass mir der Nutzen nicht die Mühe wert erscheint, so viel Abstraktion und auch Komplexität in Kauf zu nehmen.

In einem Projekt, bei dem man keinesfalls weiß, mit welchen und wie vielen Quellen das Projekt handeln muss, schon eher.
Aber ich denke, wir können unsere Quellen doch ganz gut einschätzen und einschränken.
Daher würde ich mich eher in Byrels Richtung bewegen.
Sie ist gut skalierbar und übersichtlich

Vielleicht kann man am Ende die drei Klassen von Byrel zu einer zusammenfassen, welche dann die Auswahl der benötigten Klasse trifft.

Zitat von Basti,41012

Hab ich mir in meinen autodidaktischen "Studien" einen so krassen UML-Slang beigebracht, denjetzt keiner außer mir lesen kann? Langsam komme ich ins Grübeln.

Ich denke du hast eher einer der häufigsten Entwicklerfehler begangen: Du meinst, dein Diagramm ist gut zu verstehen, weil du es entwickelt hast und die Kommentare, die andere brauchen, um es zu verstehen, direkt im Kopf hast.

So far,
Jojo


PS: Auch wenn ich es schon öfters gesagt habe und es bereits lasch klingen mag: Ich möchte mich an diesem Projekt beteiligen und "ja", meine Beteiligung wird sich erhöhen!

[Basti]

Zitat von Jojo

In einem Projekt, bei dem man keinesfalls weiß, mit welchen und wie vielen Quellen das Projekt handeln muss, schon eher.
Aber ich denke, wir können unsere Quellen doch ganz gut einschätzen und einschränken.

Es geht ja auch nicht um Datenbankabstraktion (ich entwickle im Moment z.B. nur für MySQL), denn die Queries müssen so auch alle von Hand geschrieben werden (bis auf die Standard CRUD-Funktonen natürlich - die schreibt mn nur einmal je Datenquelle). Es geht vor allem darum, die Datenbankabfragen möglichst kompakt in eine Ecke zu packen und die nicht zwischen irgenwelchem anderen Code suchen zu müssen, den man dann auch noch verstehen muss, um überhaupt drauf zu kommen, was die Anfrage bezwecken soll.

Ist also eine schöne Trennlinie, um ohne viel Kommunikation untereinander parallel an unterschiedlichen Teilen der Anwendung arbeiten zu können und eben z.B. die Datenbankabfragen optimieren zu können (oder eben auch die Datenquelle wechseln zu können), ohne einen Finger an die eigentliche Anwendung legen zu müssen.

Ich denke du hast eher einer der häufigsten Entwicklerfehler begangen: Du meinst, dein Diagramm ist gut zu verstehen, weil du es entwickelt hast und die Kommentare, die andere brauchen, um es zu verstehen, direkt im Kopf hast.

In meinem Fall ist das kein Fehler, da ihn außer mir bis Mitte November niemand verstehen muss, da ich bis dahin alleine dran sitze.

Basti

[Jojo]

Zitat von Basti

Es geht vor allem darum, die Datenbankabfragen möglichst kompakt in eine Ecke zu packen und die nicht zwischen irgenwelchem anderen Code suchen zu müssen, den man dann auch noch verstehen muss, um überhaupt drauf zu kommen, was die Anfrage bezwecken soll.

Muss ich nicht immer verstehen, was eine Anfrage bezwecken soll?
Geht es im Grunde nicht eher um die Entscheidung zwischen
Wir -> DataHandler -> Auswahl des Systems -> Daten
und
Wir -> Auswahl des Systems -> Daten
???

Oder habe ich da was falsch verstanden?

[Byrel]

@JoJo

Basti meint glaub ich das der Aufruf einer aussagekräftigen Methode den Code selbst dokumentiert.

z.B.

$obj->getUserByName ($username);

ist wesentlich schneller und besser verständlich als

$obj->query ("select * from users where username='JoJo');

Es geht vor allem um komplexe Abfragen.

MfG Byrel

[Jojo]

Achso,
aber bekommt man das nicht mit deinem Vorschlag auch hin?
Danke,
Jojo

[Byrel]

Ja, denke schon.

[Basti]

Genau das meinte ich und natürlich bekommt man das auch hin, wenn man ein ausschließlich ein Objekt für jede Entitätsmenge hat.

Ich will dieses Modell auch garnicht schlecht machen. Das Ding ist halt, dass du wahrscheilich bald auf den Trichter kommst, dass du aus deinen DataSets (wie auch immer genannt) Objekte zimmern möchtest. Irgendwann merkst du, dass du den gleichen Code schon das fünfte mal geschireben hast - nämlich aus einem DataSet/TransferObject ein DataObject bzw. eine Liste von DataObjects zu basteln und suchst nach einer Lösung, gleich deine Datenobjekte zu bekommen, wenn du bestimmte Abfragen an die Persistenz-Schicht stellst. Und dann bist du eben schon genau beim ORM angelangt.

Die beiden einzigen Gründe, darauf zu verzichten, die ich sehe sind a) die Performance und b) der Aufwand, das sauber zu implementieren.

Basti