Forum PHP.pl

Witam

Mam pytanie odnośnie współpracy PDO z własnymi klasami.

Ktory sposob powinno sie uzywac:

1. Polaczenie z baza poza klasa (wlasna) i przekazywanie do niej obiektu typu PDO. Wszystkie zapytania, operacje na danych z bazy odbywaja sie we wlasnej klasie.

2. Wszystkie operacje zwiazane z baza odbywaja sie poza wlasna klasa (zapytania, pobieranie danych), a do mojej klasy przekazuje juz np. pobrane z bazy dane.


Do tej pory caly czas pisalem strukturalnie, ale postanowilem to zmienic i oto pierwszy dylemat jaki napotkalem na swojej drodze

Ten post edytował Jawor 9.11.2008, 16:27:35

Przekazuj obiekt PDO i wykorzystuj go w klasach służących do interakcji z danymi w bazie; w tzw. modelach.

Najprostszy przykład:

[PHP] pobierz, plaintext 
<?php
class News
{
    protected $pdo;
 
    public function __construct(PDO $pdo)
    {
        $this->pdo = $pdo;
    }
 
    public function getAllNews()
    {
        $statement = $this->pdo->query('SELECT * FROM news');
        return $statement->fetchAll();
    }
 
    // etc
}
?>
[PHP] pobierz, plaintext 

Są oczywiście lepsze rozwiązania

Edit:

Klasa news nie powinna mieć nic wspólnego z prezentacją danych.
Może pobierać, kasować i zmieniać newsy w bazie, ale na przykład nie może wypluć HTML.

Ten post edytował LBO 9.11.2008, 16:40:35

Rozwiniesz ?

Ten post edytował Jawor 9.11.2008, 16:41:38

Ok. Dzieki za pomoc.

Pozdrawiam

Z ostatnich testów i odrobiony teoretyzowania wyszło mi że nie bardzo opłaca się przekazywać context w konstruktorze bo wyobraźmy sobie następującą systuację:

[PHP] pobierz, plaintext 
<?php
    $context = new Context(); // obiekt $context nie zawiera listy obiektów
    $config = New Config($context); // obiekt $config dopisuje sam siebie do obierktu $context;
    $log = New Log($context); // obiekt $context zawiera teraz $config + $log;
    $dbDriver = new Db_Driver($context) // w tym miejscu $context ma juz 3 obiekty;
?>
[PHP] pobierz, plaintext 

I teraz przykłąd użycia $log'u wewnątrz metody $dbDrver'a

[PHP] pobierz, plaintext 
<?php
    (..)
    public function printLoggedErrors()
    {
        $this->log->printErrors(QUERY_ERRORS); //ten przykład zadziała bezproblemowo;
    }
    (..)
?>
[PHP] pobierz, plaintext 

problem pojawia się kiedy chcemy za pomocą $log'u wywołać $dbDriver. Systuacja taka przytrafia się jeśli log ma zapisać cos do bazy danych. Ponieważ $dbDriver został utowrzony po obiekcie $log, log nie moze z niego korzystać.

Rozwiązaniem tego może więc być metoda ustawiająca context:

[PHP] pobierz, plaintext 
<?php
    $context = new Context();
    $config = New Config();
    $log = New Log();
    $dbDriver = new Db_Driver();
    //inicjowanie kontextu:
    $config->setContext($context);
    $log->setContext($context);
    $dbDriver->setContext($context);
?>
[PHP] pobierz, plaintext 

Proszę o komentarz do takiego rozwiązania ponieważ ciągle jeszcze staram się to udoskonalić.

Ten post edytował Black-Berry 9.11.2008, 17:32:05

Prędzej

[PHP] pobierz, plaintext 
<?php
$context = new Context();
$context->setDbDriver($dbDriver);
$context->setLogger($logger);
 
// a potem
 
$controller = new News_Controler();
$controller->setContext($context);
 
// albo
 
 
$model = new NewsModel();
$model->setContext($context);
?>
[PHP] pobierz, plaintext 

A nie tak:

[PHP] pobierz, plaintext 
<?php
$context = new Context();
    $context->setDbDriver($dbDriver = new dbDriver);
    $context->setLogger($logger = new Logger);
?>
[PHP] pobierz, plaintext 

?

Czy nie jest wadą, że obiekty $dbDriver i $log będą niewidoczne dla całej apilikacji? Wygodne byłoy przecież w stopce aplikacji wywyołać sobie np:

[PHP] pobierz, plaintext 
<?php
    $log->printErrors();
?>
[PHP] pobierz, plaintext 

a nie:

[PHP] pobierz, plaintext 
<?php
    $someControlerOrModel->log->printErrors();
?>
[PHP] pobierz, plaintext 

Ja za stopkę aplikacji uważam na przykład ostatni filtr kontrolera (coś jak pluginy front controlera w zendzie) i tam tez mam dostęp do kontekstu.

Jest hermetycznie, poza aplikacja nie ma dostępu do żadnych driverów, loggerów etc.

Racja. Twoje rozwiązanie jest bardziej eleganckie.

pozdrawiam.

Dajcie już spokój z tymi kontekstami i kopiowaniem wszystkiego z Javy... Ja do tego wykorzystuje wzorzec Registry.

[PHP] pobierz, plaintext 
<?php
class ApplicationRegistry extends Registry {
    private static $instance;
      private $values = array();
      
    private function __construct() {
    }
    
    /**
     * Enter description here...
     * @return ApplicationRegistry
     */
    public static function getInstance() {
      return self::$instance ? self::$instance : self::$instance = new self();
    }
      
    /**
     * Gets PDO Database Access
     * @return PDO
     */
    public static function getPDO() {
      return self::getInstance()->get('pdo');
    }
    
    public static function setPDO($object) {
      if ($object instanceof PDO)
        self::getInstance()->set('pdo', $object);
      else
        throw new Exception('Obiekt musi być instancją klasy PDO.');
    }
      
  }
?>
[PHP] pobierz, plaintext 

Wywołanie:

[PHP] pobierz, plaintext 
<?php
$pdo = ApplicationRegistry::getPDO();
?>
[PHP] pobierz, plaintext 

Ten post edytował markac 9.11.2008, 20:17:28

Rejestr to tylko niechlujność architektów :/

Przeczy hermetyzacji OOP. Po to mam obiekt kontekstu, żeby go przekazywać gdzie chcę, a tam, gdzie nie - to go nie ma.



A nie wiesz, że poniekąd z Javy wywodzą się najlepsze praktyki programistyczne?

Ten post edytował LBO 9.11.2008, 20:34:25

Singletony są złe. A poza tym działają wolniej niż context.

@BlackBerry:
A czy przypadkiem nie jest tak, że context powinien być singletonem? Przykład:
http://www.symfony-project.org/api/1_1/sfC...hod_getinstance
Chyba nie powiesz, że Symfony projektowały osoby nie znające się na OOP...

No i w tym momencie masz z poziomu szablonu dostęp do bazy, o! A nie powiesz mi chyba, że to dobrze?


Zrobili to dla wygody tylko.

edit

Wynika to z architektury Mojavi, gdzie aplikacja jest uruchamiana z poziomu kontekstu, a ten trzeba jakoś pozyskać.

Ten post edytował LBO 10.11.2008, 09:54:19

Tak się składa, że obiekt bazy danych ma być dostępny w większości przypadków wszędzie i przekazywanie tego uchwytu do każdego obiektu, np. przez konstruktor to dla mnie przerost formy nad treścią. A jak byście nie wiedzieli, kontekst także jest singletonem, czyli co, źle? Ależ skąd. Kontekstu nie używa się tylko po to, żeby zapewnić dostęp dostęp do wspólnych obiektów, które posiadają tylko jedną instancję. Używa go się tam, gdzie zachodzi możliwość uruchomienia skryptu w innym środowisku (kontekście), że tak to ujmę W tym wypadku kontekst wykorzystujecie tylko i wyłącznie do przekazania obiektu bazy danych i ja mówię temu nie. Lepszym rozwiązaniem jest dla mnie w tym wypadku Rejestr, ale jak kto woli...

Dlaczego na miłość Boga kontekst miałby być singletonem Dlaczego mielibyśmy przekazywać coś w konstruktorach ?

[PHP] pobierz, plaintext 
<?php
//creating core objects...
    $config = new Config();
    $log = new Log();
    $dbDriver = new Db_Driver();
    $session = new Session();
    
    //creating context...
    $context = new Core_Context();
    $context->setConfig($config);
    $context->setLog($log);
    $context->setDbDriver($dbDriver);
    $context->setSession($session);
    
    //setting context...
    $log->setContext($context);
    $dbDriver->setContext($context);
    $session->setContext($context);
?>
[PHP] pobierz, plaintext 

Kto Ci powiedział, że obiekt kontekstu ma być wszędzie?

To ja napiszę tak i się powtórzę - singletony PRZECZĄ hermetyzacji. Idealna aplikacja powinna wyglądać tak, że ją odpalasz jakimś obiektem aplikacji i koniec, wszystko się dzieje wewnątrz, a ty nie masz do niczego dostępu, zarazem zachowując pełną kontrolę.

Niech szlak trafi ZF za rozpropagowanie tego cholernego wzorca. Zrobili zbiór klas, które działają tak luźno, że nie sposób nie korzystać z rejestru.

Nie po to w architekturze oprogramowania wymyśla się nieprzepuszczalne warstwy (czyli nie mówię tylko o MVC), żeby jakiś rejestr odstawił wszystko do lamusa. Weźmy na przykład aplikacje GUI, które trzymają się MVC - gdyby we frameworkach wspomagających tworzenie takiego oprogramowania warstwy by rzeczywiście na siebie nie zachodziły to by było super - a tak nadal się zdarza, że żółtodziub siada do klawy i zasysa dane bezpośrednio w akcji np. Button.onClick (co zasadniczo jest widokiem, a raczej szablonem jeżeli przerzucić to na myślenie WWW).

Rejestr to taki kontekst dla leniwych.

troche odgrzewam temat, ale przyznam, że cos mnie gryzie
jak poinien wygladac element, ktory jest trzymany jako $context?

[PHP] pobierz, plaintext 
<?php
$this->context->getPDO()->query('SELECT * FROM news');
?>
[PHP] pobierz, plaintext 

bo z tego co rozumiem, $context to klasa, ktora zawieta min jakies odwolnie do PDO.
czy nie lepiej przed wywolaniem instancji naszej klasy News() wywoalac instacje od PDO() i pozniej przekazac uchwyt do News() ?
Sory, jesli cos pomieszalem, ale to moje poczatki w oop

Tak też można, jeżeli nie chcesz by News miał dostęp do czegokolwiek innego niż PDO to możesz o tak:

[PHP] pobierz, plaintext 
<?php
class Model
{
    private $context;
    
    public function initialize(Context $context)
    {
        $this->context = $context;
    }
 
    protected function getPDO()
    {
        return $this->context->getPDO();
    }
}
 
 
class News extends Model
{
     public function getAllNewsByPage($page)
     {
         $pdo = $this->getPDO();
         // tutaj robisz selecty etc.
     }
}
?>
[PHP] pobierz, plaintext 

Ten post edytował LBO 22.11.2008, 17:13:17