dedlfix: Zend_DB - weder toll noch un-toll, u.U. einfach praktisch

Beitrag lesen

echo $begrüßung;

Aus meiner Sicht abstrahieren die Klassen aber ganix. Sie bilden ein einheitliches Interface (Zend_Db_Adapter_Abstract) für ein PDO, unabhängig vom dahinterstehenden RDBMS.

Genau das ist die Abstraktion an der Stelle, die Bildung einer einheitlichen Oberfläche unabhängig von der dahinterstehenden konkreten Implementation. Außerdem ist ja nicht nur PDO vertreten, sondern auch diverse native Implementationen (mysqli neben PDO_mysql beispielsweise). Verwechsle bitte nicht diese Abstraktion des DB-Zugriffs und dessen Oberfläche/Schnittstelle mit den Begriffen Interface und abstrakte Klassen/Methoden aus der OOP. Stell dir einfach vor, der DB-Layer wäre nicht in OOP realisiert und dann tauchten die OOP-Schlüsselwörter abstract und interface nicht auf. Es bleibt aber, dass der DB-Layer eine Abstraktion unterschiedlicher DBMS ist und eine Schnittstelle hat, über die das Hauptprogramm mit ihm kommuniziert.

Zend_Db_Statement (basieren auf PDOStatement)

(Vom Funktionsumfang gesehen mag das vielleicht so sein, nicht aber von der Vererbung/Klassenhierarchie.)

Zend_Db_Select-Objekt

Beides sind Abstraktionen. Zend_Db_Statement ist die Abstraktion eines Prepared Statements und Zend_Db_Select die eines SQL-SELECT-Statements.

Mal pointiert in den Raum gestellt: abstrahiert wird da aus meiner Sicht garnix, oder verstehe ich "Abstraktion" falsch?

Ja, du verstehst das anscheinend falsch.

Das ist doch einer eine Frage der "Convinience".

So eine Abstraktion ist "convenient" (angenehm, komfortabel, bequem, ...), weil man eine einheitliche Oberfläche/Schnittstelle hat und nicht mehrere. Und Convenience ist das Ziel der Abstraktion (das man sich mit zusätzlicher Komplexität erkauft, auch wenn es nach außen hin einfacher aussieht als ein Zugriff über konkrete DBMS-individuelle Komponenten).

Ein Interface ist doch keine Abstraktion im Sinne eines ORM, oder?

Welches Interface meinst du? Das aus der OOP ist hier fehl am Platz. Und ein ORM hat natürlich zwei Schnittstellen, eine zum DBMS hin und eine zum Hauptprogramm hin. (Und die Implementation in OOP verwendet möglicherweise Interfaces, aber das ist eine andere Geschichte.)

Ist ein ORM eine Abstraktion? Meiner Meinung nach nicht unbedingt. In erster Linie sehe ich es als eine Konvertierschicht zwischen zwei Philosophien, mit Daten umzugehen. Eine Abstraktion wird es dann, wenn es unterschiedliche Arten des Zugriffs vereinheitlicht. "Unter" dem ORM ist es ja schon einheitlich. Entweder durch den DB-(Abstraktions-)Layer oder weil der ORM nur auf einem einzigen DBMS aufsetzt. Es mag sicher auch Implementationen geben, wo ORM und DB-Layer eins sind und dann noch diverse DBMS bedient werden können. Dann konvertiert und abstrahiert dieses Konglomerat in Personalunion (und hat eine Schnittstelle über die die Programmlogik zugreift).

Ich dacht eher eine einheitliche Schnittstelle, um im o.g. Falle a) unabhängig vom dahinterliegenden Datenbanksystem codieren zu können und b) von anderen Klassen des Frameworks genutzt zu werden.

Abstraktion eben.

echo "$verabschiedung $name";

0 43

sqlite - gibts gründe, das nicht zu nutzen?

frankx
  • datenbank
  1. 1
    dedlfix
    1. 0
      frankx
      1. 0
        frankx
        1. 0
          dedlfix
          1. 0
            frankx
          2. 0

            Zend_DB - weder toll noch un-toll, u.U. einfach praktisch

            frankx
            1. 1
              dedlfix
              1. 0
                frankx
                1. 0
                  dedlfix
                  1. 0
                    frankx
      2. 0
        dedlfix
        1. 0
          frankx
          1. 0
            dedlfix
  2. 0

    sqlite vs. serialisiertes Array

    frankx
    1. 0
      dedlfix
      1. 0
        frankx
        1. 1
          Ilja
          1. 0
            frankx
    2. 0
      Sven Rautenberg
      1. 0

        sqlite vs. serialisiertes Array - welcher Vartyp für welche Vars

        frankx
        1. 0
          Sven Rautenberg
          1. 0
            frankx
            1. 1
              Sven Rautenberg
              1. 0
                frankx
                1. 0
                  Sven Rautenberg
                  1. 0

                    ein Grund, SQLite nicht zu nutzen

                    Vinzenz Mai
                    1. 0
                      frankx
                    2. 0
                      Sven Rautenberg
                      1. 0
                        frankx
                        1. 0
                          Vinzenz Mai
                          1. 0
                            ChrisB
                        2. 1
                          Sven Rautenberg
                          1. 0
                            frankx
                            1. 0
                              Sven Rautenberg
                              1. 0
                                frankx
        2. 1
          dedlfix
          1. 0
            frankx
            1. 0
              dedlfix
              1. 0
                frankx
                1. 0
                  dedlfix
          2. 0

            ALTER TABLE = schlechtes Design - serialisierte PHP Daten

            frankx
            1. 0
              dedlfix