PHP Data Access Object

Ich versuche herauszufinden, wenn ich mit der DAO-pattern korrekt und konkret wie Abstrakt db Ausdauer sollte durch die Zeit, die Sie bekommt, um meine mapper-Klassen. Ich bin mit PDO als data-access-Abstraktion-Objekt, aber manchmal Frage ich mich, wenn ich versuche zu abstrahieren, dass Abfragen zu viel.

Habe ich nur aufgenommen, wie ich bin, abstrahiert select-Abfragen, aber ich habe geschrieben, Methoden für alle CRUD-Operationen.

class DaoPDO {

    function __construct() {

        //connection settings
        $this->db_host   = '';
        $this->db_user   = ''; 
        $this->db_pass   = ''; 
        $this->db_name   = '';


    }

    function __destruct() {

        //close connections when the object is destroyed
        $this->dbh = null;

    } 


    function db_connect() {

        try { 

            /**
             * connects to the database -
             * the last line makes a persistent connection, which
             * caches the connection instead of closing it 
             */
            $dbh = new PDO("mysql:host=$this->db_host;dbname=$this->db_name", 
                            $this->db_user, $this->db_pass, 
                            array(PDO::ATTR_PERSISTENT => true));


            return $dbh;

        } catch (PDOException $e) {

            //eventually write this to a file
            print "Error!: " . $e->getMessage() . "<br/>";
            die();

        }


    } //end db_connect()'



    function select($table, array $columns, array $where = array(1=>1), $select_multiple = false) {

        //connect to db
        $dbh = $this->db_connect();

        $where_columns  = array();
        $where_values   = array();

        foreach($where as $col => $val) {

            $col = "$col = ?";

            array_push($where_columns, $col);
            array_push($where_values, $val);

        }


        //comma separated list
        $columns = implode(",", $columns);

        //does not currently support 'OR' arguments
        $where_columns = implode(' AND ', $where_columns);



        $stmt = $dbh->prepare("SELECT $columns
                               FROM   $table
                               WHERE  $where_columns");


        $stmt->execute($where_values);

        if (!$select_multiple) {

            $result = $stmt->fetch(PDO::FETCH_OBJ);
            return $result;

        } else {

            $results = array();

            while ($row = $stmt->fetch(PDO::FETCH_OBJ)) {

                array_push($results, $row);

            }

            return $results;

        }



    } //end select()


} //end class

So, meine zwei Fragen:

Ist dies die richtige Verwendung des DAO, oder bin ich falsch es ist Zweck?
Ist die Abstraktion der query-Prozess in diesem Maße unnötig, oder gar unüblich? Manchmal habe ich das Gefühl, ich bin zu versuchen, die Dinge zu einfach...

InformationsquelleAutor jerry | 2012-06-29

20

Sieht es eher wie baut man eine Persistenz-Abstraktionsschicht auf der Oberseite PDO (der selbst eine Persistenz-Schicht) eher als eine data access object. Zwar gibt es viele Formen, die ein DAO nehmen kann, das Ziel ist die Trennung der Geschäftslogik von Persistenz-Mechanismus.
```
  Business Logic
        |
        v
Data Access Object
        |
        v
 Persistence Layer
```
Einer DAO mit db_connect und select ist zu eng nach dem Vorbild des Persistenz-Schicht. Die einfachste form eines generischen DAO ist es, die grundlegenden CRUD-Operationen auf ein Objekt Ebene, ohne dass die Interna der Persistenz-Mechanismus.
```
interface UserDao
{
    /**
     * Store the new user and assign a unique auto-generated ID.
     */
    function create($user);

    /**
     * Return the user with the given auto-generated ID.
     */
    function findById($id);

    /**
     * Return the user with the given login ID.
     */
    function findByLogin($login);

    /**
     * Update the user's fields.
     */
    function update($user);

    /**
     * Delete the user from the database.
     */
    function delete($user);
}
```
Wenn Sie Ihre business-Objekte sind das zugrunde liegende PDO-model-Objekte, können Sie zurück aus dem DAO. Beachten Sie, dass je nach der zugrunde liegenden Persistenz-Mechanismus, die Sie wählen, kann dies nicht ideal ist. Ich habe nicht gearbeitet mit PDO, aber vermute, es ist ähnlich zu anderen ORM-tools, die das produzieren, standard-PHP-Objekte ohne binden, die die business-Logik für die PDO-API. Sie sind also wohl in Ordnung hier.

Wenn Sie die Implementierung der Persistenz durch den Zugriff auf die mysqli Bibliothek direkt, zum Beispiel, würden Sie wollen, um Daten kopieren zu/von Ergebnismengen in Ihrer eigenen model-Objekte. Dies ist die Aufgabe des DAO, um es aus der business-Logik.

Durch die Verwendung einer Schnittstelle für die DAO setzen Sie diese für verschiedene Persistenz-frameworks: PDO, Doctrine, raw-SQL, was auch immer. Während Sie wahrscheinlich nicht wechseln, Methoden Mitte-Projekt, die Kosten der Verwendung einer Schnittstelle vernachlässigbar klein ist im Vergleich zu seinen anderen Vorteile, wie z.B. die Verwendung eines mock in unit-Tests.

Also jedes Domain-Objekt in der Domäne Modell könnte/sollte eine Verwandte Dao-Objekt für die CRUD-Operationen dann?
Jedes root-Objekt, ja. Zum Beispiel, ein Order sowie eine Liste von LineItem Kinder würden wahrscheinlich zusammen gelagert werden, durch OrderDao. Leider kann man selten ganz isolieren Sie die business-Logik aus, wie Sie fortbestehen der domain model-Objekte.
Okay, das bringt tatsächlich eine Frage, und dann werde ich das akzeptieren und geben Sie die bounty. Sie erwähnen LineItem Kinder, und ich möchte sichergehen, dass ich würde sein Umgang mit diesen richtig in meiner Anwendung. Würden diese Kinder Karte, um Tabellen in der db (a LineItem-Tabelle) und nur konsolidiert werden, Um die domain-Objekt von Dao? d.h. eine createObject-Methode in der DaoUser wäre das ein zu bringen diese beiden Objekte zusammen?
Edit: würde eine createObject-Methode in der OrderDao werden, in denen Elemente werden zusammengefasst und bilden das Domain-Objekt?
Ja, das ist richtig. Dies ist nicht zwingend, aber die Argumentation ist für die Behandlung einer Bestellung und deren Elemente als ein in sich geschlossenes Objekt (Kapselung). Es verringert auch auf die Anzahl der DAOs, die Sie haben zu bauen, obwohl, können Sie wahrscheinlich generieren Sie den code für die grundlegenden Operationen.

InformationsquelleAutor David Harkness
0
1. Es ist nicht unbedingt notwendig, aber es ist sicherlich gängige Praxis. Es gibt viele Bibliotheken, die abstrakte waaaaay weiter als das, was du tust 🙂
InformationsquelleAutor Lusitanian

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.