Basti

Hallo.

Folgendes Problem:

Ich hab verschiedene Module mit je einem DAO. Diese DAOs sollen auf verschiedene Datenquellen zugreifen können und ich frag mich, wie ich das am geschicktesten umsetzen kann. Habt ihr da gute Lösungen parat?

Da einen Überbau mit Abstrakter Fabrik zu hinzusetzen, die für jeden Datenquellen-Typ eine konkrete Fabrik zurückgibt finde ich ein wenig übertrieben - zumindest falls sich nichts einfacheres findet. Aber auch dabei ist das Problem, dass die Verbindungsdaten, also die verfügbaren Datenquellen in der Anwendungs-Konfiguration definiert werden und das komplette Laden der Klassen über __auotload() läuft. Also irgendwie nicht so gut, hier Fehlkonfigurationen abzufangen, oder gibt es da gute Ansätze?

Habt ihr dazu Ideen oder beschränkt ihr DAOs gundsätzlich auf eine Datenquelle (ggf. auch einzelne Tabelle) und bastelt die Abfrageergebnisse dann in den Model-Klassen zusammen?

Basti

Mister Ad

HStev

Muss ja nicht unbedingt ne abstrakte Fabrik sein aber ne Factory wäre da schon ein guter Ansatz oder hälts du das auch für übertrieben?

__________________
Gewisse Dinge behält man besser für sich, z.B. das man gewisse Dinge für sich behält.

Basti

Hi.

Eine Factory erzeugt ja Objekte, deren Schnitstelle klar definiert ist. In meinem Fall will ein Client ein Objekt, dass eine MySQL-Verbindng mit MySQL-spezifischen Methoden anbietet, ein anderer will ein Objekt, mit der er irgendeinen Web-Service ansteuern kann, der ganz andere Methoden bereit hält. Folglich taugt hier eine Factory nicht.

Ob ein Mittelding, also ein Objekt, dass mehrere unterschiedliche Zugriffs-Objekte erstellen kann (für das es wahrscheinlich auch ein Pattern/einen Namen gibt) sinnig ist, weiß ich nicht so recht. Man könnte anhand des aus der Konfiguration für die angefragte Datenquelle ausgelesenen Typs den Namen der zu erzeugenden Klasse zusammenbasteln und von der dann über eine statische Methode ein Objekt ihrer selbst zurückgeben lassen (womit die Entscheidung, ob die Klasse als Singleton implementiert werden muss oder nicht in den Klassen selbst bleibt).

Aber so ganz gelungen find ich das nicht.

Basti

PS:
Die DAOs wissen ja um den Typ. Von daher könnte man von einer solchen ... wie nennt man so eine "Multi-Fabrik"? ... auch konkret die spezifischen Objekte anfragen: DataAccessFactory::getMySQLAccess('user_db'); Damit wären die Klassennamen raus aus der Konfiguration.

HStev

Dieser Grund wäre für mich Grund genug eine Factory zumindest für ein Verbindungsobjekt ( muss ja nicht gleich die komplette DB Klasse sein ) einzusetzen.

Ansonsten verstehe ich dann nicht wirklich was du bezweckst.

__________________
Gewisse Dinge behält man besser für sich, z.B. das man gewisse Dinge für sich behält.

Basti

Was für ein Verbindungsobjekt meinst du?

Basti

Du kannst es wie PDO umsetzen. Nach aussen immer die selbe Klasse, die intern den spezifischen Treiber verwendet.

HStev

Objekt war hier vielleicht ein etwas unglückliches Wort aber du sagtes das du mehrere Verbindungen hast aber immer zu MySQL, richtig?
Warum verbindest du nicht einfach eine Singleton mit einer Factory?
In der Factory cachst du alle Verbindungresourcen und gibst entweder neue oder bestehende zurück.

Wenn du unterschiedliche Datenbanken ansprechen willst, brauchst du unterschiedliche Objekte mit denselben Public Methoden.

__________________
Gewisse Dinge behält man besser für sich, z.B. das man gewisse Dinge für sich behält.

Basti

Nein, ich möchte es schon ermöglichen, die Abfragen für ein DBMS etc. zu optimieren. D.h. das DAO enthält im Falle einer MySQL-Verbindung eine MySQL query und setzt diese an das Verbindungs-Objekt ab.

Eben nicht. Sonst könnte ich die MySQL-Geschichten auch einfach in die abstrakte DAO-Klasse packen, von der die konkreten DAOs abgeleitet werden. Do bräuchte es dann nichtmal eine eigene Factory (nur eben für die DAOs, aber die gibt es eh)

Das ist ja eben das Problem. Die Objekte der unterschiedlichen Datenquellen bieten unterschiedliche Methoden an. Diese Objekte sind ganz simple Dinger, die z.B. im Falle von MySQL einmalig vorliegen, das Vebindungs-Handle speichern und eine Methode zur übergabe einer Query und der darin einzusetzenden Parameter enthält.

Ein solches Objekt für den Zugriff auf einen RSS-Feed hat aber natürlich keine Methode, eine Query einzugeben, sondern vielleicht nur "gibMirDieErstenXDatensätze(x)".

Allen diesen Objekren gemein ist, dass die ein Ergebnis-Objekt zurückgeben, dass dann wieder über eine einheitliche Schnittstelle ausgelesen werden kann.

Vielleicht bin ich da auch generell auf dem Holzpfad, aber in meinen Augen macht soweit erstmal Sinn.

Basti

Die zurückgelieferten Objekte sollen also unterschiedliche (spezialisierte) Schnittstellen haben und auch so verwendet werden?
Dann brauchst Du da auch nichts kapseln oder abstrahieren, da der umgebende Code eh' schon wissen muss, was genau er mit dem Objekt anstellen kann.

HStev

Willst du auf fertige Sachen zurückgreifen?
Also meine MySQL Klasse enthält selbst geschriebene Mehtoden. Müsste ich jetzt eine für Oracle schreiben würde die auch eigene Methoden besietzten wobei die Public Mehtoden mit denen aus der MySQL Klasse übereinstimmen würden gerade aus dem Grund damit ich die "gleichzeitig" per Factory verwenden kann.

__________________
Gewisse Dinge behält man besser für sich, z.B. das man gewisse Dinge für sich behält.