php - PDO objekt deling... - Udvikleren.dk - Programmering, webdesign og grafik

Tags: php pdo

Bruger #17015 @ 22.04.12 19:03

Hej venner :-)

Jeg kunne godt tænke mig at høre jeres mening om følgende:

Jeg har haft funderet en del over hvordan man bedst deler et PDO objekt mellem flere forskellige objekter som skal interagere med databasen. Jeg har ikke kunnet finde nogen svar konkrete svar nogen steder - og jeg har set folk gøre det på mange måder. Det er nok ikke specifikt for pdo - det gør sig nok gældende for, for eksempel, mysqli.

Man kunne give db-objektet gennem constructors. Eller man kunne have det i en variabel, som man gav objektet adgang til via global keywordet. Man kunne også overveje, om det overhovedet er et problem at have flere forskellige instances af PDO objektet. Jeg har ikke testet det, da min logik siger at én forbindelse der deles mellem alle er bedre end en forbindelse per objekt.

Der er mange muligheder. Jeg er dog kommet frem til en metode som jeg synes er den mest optimale - men den er lidt rough. Og selvom jeg synes den er funktionel nok - så er jeg usikker på om det er "the way to go".

Det ser således ud:

PHP kode

 $_dbh = 0;
 
 function createConnection() {
   global $_dbh;
   $_dbhost = 'host'; 
   $_dbuser = 'user';
   $_dbpass = 'pass';
   $_dbname = 'database';
   $_dbh = new PDO("mysql:host=$_dbhost;dbname=$_dbname", 
                   $_dbuser, 
                   $_dbpass, 
                   array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8"));
   $_dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
 }
 
 function getConnection() { 
   global $_dbh; 
   if (!is_object($_dbh)) { createConnection(); }
   return $_dbh;
 }

Når jeg så skal bruge min connection gør jeg bare noget ala:

PHP kode

 $db = getConnection();
 $stmt = $db->prepare(....);

Nemt og fikst synes jeg selv.

Kan i finde nogen svagheder ved den metode? Eller er der nogen helt åbenlyse ting som overser - som gør det fuldstændigt overflødigt?

Indlæg senest redigeret d. 22.04.2012 19:03 af Bruger #17015

9 svar postet i denne tråd vises herunder
2 indlæg har modtaget i alt 6 karma

Sorter efter stemmer Sorter efter dato

Bruger #10216 @ 23.04.12 10:41

4.283

Man siger gerne at singleton er et anti-pattern. Grundet at Singletons vist nok ikke tillader Dependency Injection.

Men alternativt kan du som jeg skrev tidl. bruge en wrapper, der gør brug af singleton og registry pattern. Anvendeligheden er den samme - men det giver mulighed for DI.

PHP kode

 <?php
 class Connection {
     private static $pdo_registry = null;
     
     public function query($sql) {
         return self::getConnection()->query($sql);
     }
     
     private static function getConnection() {
         if(!self::$pdo_registry) {
             self::$pdo_registry = new PDO(...);
         }
         return self::$pdo_registry;
     }
 }
 
 
 $db = new Connection();
 $db->query('SELECT...');
 
 
 $db = new Connection();
 $db->query('SELECT...');

Indlæg senest redigeret d. 23.04.2012 15:18 af Bruger #10216

Bruger #10216 @ 22.04.12 19:19

4.283

Man siger at, globale variabler er vejen til forvirring.

Men det kommer lidt an på hvilken vej du vil gå - men som udgangspunkt, hvis du vil bruge OOP, så nøjes med det og undgå procedural kode. Men du kan bruge registry-pattern, et singleton-pattern.

Singleton - det betyder dog at du skal lave en wrapper:

PHP kode

 class Database {
     ...
     static public function getInstance() {
         if(!self::$instance) {
             self::$instance = new self();
         }
         return self::$instance;
     }
 
     private function __construct() {
         $this->adapter = new PDO(...);
     }
 }
 
 $db = Database::getInstance();

Registry:

PHP kode

 class DatabaseRegistry {
     ...
     static public function register(\PDO $pdo) {
         return self::$registry = $pdo;
     }
 
     private function registry() {
         return self::$registry
     }
 }
 
 $db = DatabaseRegistry::registry();

Jeg arbejder pt. med en blanding af disse, hvor det så tillader mig at lave objekt-instanser af en wrapper klasse.

Bruger #17015 @ 22.04.12 20:57

614

Ja jeg glemte at nævnte singleton mønstret.

Ja - globale variable er farlige - derfor prefixer jeg dem - som fx $_dbh - og så længe man holder det i det små er det vel fint. Jeg har også hørt mange kritiske ryster omkring singleton-metoden. :-) Jeg kan dog ikke huske hvad det konkret handlede om - dog var det på et ret teoretisk plan.

Men i store træk så er idéen i både singleton-klassen og mine to funktioner jo det samme. Formen er bare forskellig :-)

Man burde nok holde rene-linjer og tage singleton udgaven.

Bruger #2695 @ 23.04.12 11:11

1.963

Singleton ér et kæmpe antipattern, men du kan jo bruge en factory. Det har jeg selv brugt meget i et større system, og det virker EXCELLENT!!!

Her er lidt af min factory:

PHP kode

 clas re_AContext implements re_IContext {
         public function getBuildDAO() {
             return isset($this->objectCache[__FUNCTION__]) ? $this->objectCache[__FUNCTION__] : $this->objectCache[__FUNCTION__] = 
             new re_BuildDAO($this->getRealeaseDatabase());
         }
 
         public function getGameInfoHeuristics() {
             return isset($this->objectCache[__FUNCTION__]) ? $this->objectCache[__FUNCTION__] : $this->objectCache[__FUNCTION__] = 
             new re_SubversionGameInfoHeuristics(
                 $this->getSubversionListProvider(),
                 $this->getSubversionCheckoutProvider(),
                 $this->getGameDAO()
             );
         }
 }

En hel masse metoder er undladt. Mit Context objekt ved, hvordan alting instantieres, så hvis jeg ændrer på en constructor, så skal jeg kun ændre i min Context implementation, så kører det igen.

De fleste objekter, som Context klassen opretter, bliver cachet (det er den første linje i funktionen.

Factory object er et skidegodt pattern!!

Bruger #17015 @ 23.04.12 15:14

614

Det kan godt være jeg ikke fatter hvordan interfaces virker - men umiddelbart ser jeg dem mest funktionelle i projekter med mange forskellige programmører.

Det er som en abstrakt klasse som en almindelig klasse udvider. Bortset fra at et interface blot siger, at en klasse der udvider denne SKAL implementere en række metoder.

Dog er jeg ikke sikker på hvordan properties i et interface håndteres. Er de delt mellem interfaces?

Mit mål er at have flere objekter der bruger samme instans af et PDO objekt. Som for eksempel løses med Michaels singleton-løsning, eller globale variable/funktioner hvor det er tilgængeligt. Jeg er ikke helt sikker på at man kan gøre det samme med et interface...

Men dit objectCache array er en property i interfacet, som nedarves til klassen - korrekt?

Jeg synes det virker som en skidt løsning at skulle have den der isset-if-else snippet alle steder.

Men det kan være jeg bare er blank.

I hvert fald virker Singleton løsningen mest elegant. Den minder også meget om mit oprindelige udkast - funktionaliteten er den samme - min er bare ikke pakket ind i en klasse.

Bruger #2695 @ 23.04.12 15:20

1.963

Interfaces bør ikke have properties (i mange sprog kan de slet ikke).
Det er en slags kontrakt, hvor du lover, at din klasse implementerer en række metoder, men intet siger, omkring hvordan du vil implementere dem.

Nogle af mine DAO'er har en hardkodet liste af data, hvor en database er overkill. Andre gange bruger de en XML fil og andre gange igen læser jeg data fra en web server.

Interfaces er også rare i unit testing øjemed, for da kan du lave en stub, hvor metoderne kan garanteres samme udfald. Det kan du ikke, hvis udfaldet afhænger af tilgængeligheden og indholdet af f.eks. en database.

Bruger #17015 @ 23.04.12 15:40

614

I så fald ved jeg ikke helt hvordan du har tænkt dig at løse problemet med deling af et enkelt database handle med interfaces.

Hvis ikke din objectcache er delt mellem objekterne - hvordan fungerer det så?

Bruger #2695 @ 23.04.12 15:50

1.963

I min frontend kode har jeg noget i stil med følgende:

Kode

$context = new re_ConcreteContext($my_configuration);
$gameDao = $context->getGameDAO();
$builder = $context->getBuilder();

for ($gameDao->listGames() as $game) {
    $builder->build($game);
}

Mit 'builder' objekt skal faktisk bruge et game DAO objekt, men det ved jeg ikke, når jeg laver frontend kode. Da tager jeg bare det objekt, som bliver returneret af getBuilder() metoden.

Jeg skal så også bruge et game DAO objekt selv, og det skal så bruge en hel masse andet (bl.a. en database forbindelse som builder objektet også skal bruge).

Alt dette bagvedliggende ved kun mit context objekt, som implementerer factory pattern.

Context cacher også de oprettede objekter, så det objekt, getGameDAO() returnerer, er det samme som det, getBuilder() skaffer til builder objektet.

-1

Bruger #3427 @ 22.04.12 19:45

1.520

jeg hopper med på singleton vongen.

personligt har jeg en global var som hedder $lib som indeholder alle de klasser jeg normalt bruger.

etc, init_lib.php
$lib = new stdClass();
$lib->db = new Database();

og bruger så:
$lib->db->prepare(....);

PDO objekt deling...

Karma barometer (30 dage)

Modtaget

Givet

Favorit hos
Forum tråde
Artikler