Jens Clasen

Soll er ja garnicht. Für ein kleines Projekt soll er lieber gar nichts produzieren.

- Die API die er abbildet ist veraltet
- Eine Klasse, die nur eine API abbildet ist Verschwendung von Ressourcen und Programmierzeit
- Er ist ohne einen Wrapper kein Stück schlechter dran
- Das einzige Argument für so einen Wrapper ist die Austauschbarkeit des DBMS, die lässt sich aber auf anderen Wegen leichter erreichen, und mit dieser API ist sie sowieso nicht gegeben

Das hat ausschließlich was mit Pragmatismus zu tun...

Und nun geb ich's auf - ich hab langsam den Eindruck, ich red hier Suaheli.

Gruß Jens

Mister Ad

yab

Ja und, du bist vielleicht auch nicht mehr der Jüngste? Oder sollte das jetzt ein Argument sein?

Seine Klasse abstrahiert den DB-Zugriff.

Doch, wenn das Projekt unerwartet gewachsen ist und er später auf ein anderes DBMS angewiesen ist ohne derzeit auf alles Rücksicht nehmen möchte, weil genau der MySQL-Zugriff ausreichend ist.

Nein, auch wenn man ausschließlich nur diesen MySQL-Wrapper nutzen möchte, macht das Sinn. Die Gründe wurden dir auch schon mehrfach genannt, keine Ahnung, warum du das vortwährend ignorierst.

Warum aufgeben? Wenn du andere Anschauungen/Argumente als Feedback bekommst, so nennt sich das nicht Blasphemie sondern Diskussion. Wenn du Ja und Ahmen hören möchtest, dann werd Priester und geh' in die Kirche

nikosch

mysql_* veraltet finde ich auch etwas weit hergeholt.
Dass der Wrapper so nicht gut austauschbar ist, wurde ja bereits gesagt. Aber zumindest hat er über das Interface eine Schnittstelle abgebildet.

Wenn er jetzt statt überall DB_Mysql zu verwenden, das macht

und statt DB_Mysql immer my_DB verwendet, ist er schon aus dem Schneider. Muss er irgendwann die Datenbank wechseln, ändert er eben den obigen Code meinetwegen nach

und definiert eine DB_Postgres Klasse.

Problem gelöst, ohne Verrenkungen, ohne tausendfaches Suchen & Ersetzen, ohne Factory-Umbau. Alternativ könnte er auch einen Postgres-Decorator basteln.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

cortex

welch konstruktive aussage... i.a. führen solche pauschalisierungen zu unmut bei anderen usern, flamewars oder amokläufen. vielleicht bist du aber auch nur ganz besonders fortschrittlich.

cx

Jens Clasen

• Der "Hersteller" der alten MySQL-Extension schreibt in seinem Manual:
  
  Zitat:

  Zitat von http://www.php.net/manual/en/mysqli.overview.php Note: If you are using MySQL versions 4.1.3 or later it is strongly recommended that you use the mysqli extension instead.

• Die aktuell als Stable gebrandmarkte MySQL-Version ist 5.1.

Ich weiß nicht, was Ihr noch braucht, um die Extension als veraltet zu bezeichnen. Selbst der "Hersteller" rät offen von der Benutzung ab.

Und genau das ist die Urban Legend, die ich jetzt schon drei mal versucht hab zu widerlegen. Außerdem schießt sich die Katze doch schon von vornherein selbst in den Schwanz:

• Er baut jetzt einen Wrapper, damit er später mal das DBMS durchswitchen kann.
• Das Projekt wächst unerwartet so, dass er ein anderes DBMS benötigt

Ja was denn nun? Entweder man erwartet/befürchtet, das DBMS wechseln zu müssen, oder eben nicht. Wenn man eh schon von vornherein den Gedanken im Hinterkopf hat, dann kann man das doch auch gleich richtig angehen, oder?

Also ich hab den Thread jetzt eben nochmals genau studiert, und ich finde keinen einzigen Hinwaus auf diese Gründe. Selbst der TO fragt doch nach einer qualitativen Bewertung zu seinem MySQL-Wrapper. Er scheint also selbst nicht hunderprozentig sicher zu sein, dass er ihn so verwenden möchte. Wovon zum Teufel sprichst Du also? Markier mal bitte das, wovon Du denkst, dass ich es ignoriere.

Möcht ich ja gar nicht. Ich schreib jetzt nur mindestens schon zum dritten mal das gleiche, und ich bekomm immer wieder und ohne Berücksichtigung des gesagten die selben Gegenargumente. Du verwendest in #20 exakt die selbe Argumentationslinie, wie mepeisen in #10. Dazu ist von meiner Seite einfach alles notwendige gesagt.

Jein - das stimmt sowieso nur wenn er Standard-SQL geschrieben hat. Ansonsten ist bis zu einem gewissen Grad immer suchen und ersetzen angesagt. Grundsätzlich hast Du zwar Recht, das ist einer der Standard-Anwendungsfälle. Ich behaupte nur einfach, dass es alternative Lösungsansätze gibt, die ebenfalls ihre Daseinsberechtigung haben.

Drei Gegenszenarien:

1. Wenn er gleich z.B. PDO verwendet, dann kann er das einfacher haben. Der Fall Austausch des DBMS ist dort ja schon vorgesehen. Dort hätte er sich die Entwicklungszeit für den Wrapper und für die spätere Erweiterung erspart.
2. Wenn er aber einfach das Interface der DB-Extension von PHP in einem eigenen Namespace nachbaut, und diesen dann in sein Projekt injeziert, ist dies auch der Fall. Er hat sich dann aber die Entwicklungszeit für den Wrapper gespart...
3. Er könnte auch von vorn herein einen der bestehenden Wrapper einsetzen. Es gibt ja Zend_Db, AdoDb und wie sie nicht alle heißen. Auch das würde ihm die Entwicklungszeit für den Wrapper und die Erweiterung ersparen.

Alle diese Szenarien haben eines gemein:

• jedes dieser Modelle hat einen effektiv nutzbaren Mehrwert gegenüber der Eigenentwicklung
• jedes dieser Modelle spart Entwicklungskosten
• jedes dieser Modelle macht es nicht notwendig,
  
  Zitat:

  Zitat von yab derzeit auf alles Rücksicht [zu] nehmen [möchte], weil genau der MySQL-Zugriff ausreichend ist.

Zur Pauschalisierung sagte ich oben schon was
War das jetzt der Amoklauf?

Gruß Jens