Jak inicjować obiekt, gdy nie wiemy czy będzie łączył się z bazą Opcje

[Staszek27]

Cześć!
Problem jest następujący:

[PHP] pobierz, plaintext 
class Wataha {
 private $zbior = array();
 private $PDO;
 
 public function ustawPolaczenie(PDO $PDO) {
  $this->PDO = $PDO;
 }
 
 public function stworz($rasa) {
  //pobieramy psy z bazy danych razem z ich opisami, wpierw sprawdzając czy mamy psy danej rasy. załóżmy, że mamy
  foreach($wynikZapytania as $wiersz) {
    $Pies = new Pies($wiersz['imie'], TRUE); //jedynką informujemy psa, że on naprawdę istnieje
    $Pies->ustawUmaszczenie($wiersz['umaszczenie']);
    $this->zbior[] = $Pies;
   }
 }
}
[PHP] pobierz, plaintext 

No i teraz bez problemu w kontrolerze:

[PHP] pobierz, plaintext 
// laczymy sie z baza itp.
$Model = new Wataha();
$Model->ustawPolaczenie($this->PDO);
[PHP] pobierz, plaintext 

przesyłamy model do widoku, ten go obrabia i wszystko śmiga. Problem powstaje gdy nakażemy kontrolerowi pobrać jednego, konkretnego psa. Normalnie, gdy tworzymy sobie kolekcję psów, konkretny pies nie musi sprawdzać czy to konkretnie on istnieje (po co pies miałby pytać bazę czy rzeczywiście istnieje, skoro przywołujemy go do życia danymi pobranymi właśnie z tej bazy?). Natomiast gdy chcemy powołać do życia jednego psa musimy sprawdzić czy on rzeczywiście sobie tam siedzi (np. użytkownik dopuszcza się literówki)!

[PHP] pobierz, plaintext 
class Pies {
 private $imie;
 private $umaszczenie;
 
 public function __construct($imie, $sprawdzony = FALSE) {
  if($sprawdzony) {
   $this->imie = $imie;
   return TRUE;
  }
   //pytamy bazę czy taki pies się w niej znajduje
 }
 public function ustawUmaszczenie($umaszczenie) {
   //ustawiamy umaszczenie
 } 
}
[PHP] pobierz, plaintext 

i teraz gdzieś w kontrolerze:

[PHP] pobierz, plaintext 
$Model = new Pies($imie); // drugi parametr jest równy zero, więc pies upewni się czy może istnieć
[PHP] pobierz, plaintext 

No i widzimy, że ten kod nie ma racji bytu, ponieważ pies nie ma dostępu do połączenia z bazą danych. Kontroler musi mu je jakoś przesłać. Oto garść moich pomysłów, każdy mi nie odpowiada:
1) Na konstruktor zrzucamy jedynie odpowiedzialność za dowiedzenie się czy trzeba będzie sprawdzać swoje istnienie i ew. kontroler mu połączenie. Jeśli zajdzie potrzeba już konkretną metodą proponujemy mu imię a on albo przyjmuje je bezdyskusyjnie albo je weryfikuje.
2) Pozostawiamy konstruktor pusty i w zależności od potrzeb wykonujemy wszystkie zadania ?ręcznie?.
W obu rozwiązaniach pies nie wie od razu jak się nazywa (dopiero potem proponujemy mu imię), a to chyba nie jest zbyt dobry pomysł (a może jest? tego nie wiem)? Można także:
3) Pies jest bardzo nieufny i niezależnie od wszystkiego sprawdza swoje imię. Jeśli tworzymy kolekcję 100. psów, to 100 na 101 zapytań jest całkowicie niepotrzebnych (sprawdza poprawne dane).
4) Konstruktor psa odwołuje się do prywatnej metody, która pobiera z kontrolera połączenie z bazą. Wtedy każda klasa mogłaby sobie pytać bazę, wystarczyłoby że pobierze z kontrolera dane o połączeniu. Równie dobrze mógłbym użyć singletona lub zmiennej globalnej, a tego chciałbym uniknąć?
W jaki sposób wybrnąć z tego problemu? Chodzi mi o rozwiązanie, które ma ?ręce i nogi? (tutaj raczej: cztery łapy), a o takie chyba nietrudno, bo problem wydaje się dość częsty, tylko trzeba go wpierw choć raz rozwiązać a z tym mam problem?

Ten post edytował Staszek27 25.07.2010, 20:43:12

[Pilsener]

Po mojemu to:
- model danych powinien być oparty o założenie jeden model = jedna tabela bazy danych
- w modelu nie powinniśmy ustanawiać połączenia z bazą a już tym bardziej wywoływać go z poziomu kontrolera
- w modelu nie powinniśmy definiować pól typu "zbiór", wszystkie metody powinny robić return efektów swoich działań

Ja bym stworzył klasę model_podstawowy (pal licho nazwę), która obsługuje bazę i wszystkie proste zapytania typu delete czy insert, to w niej byłaby instancja klasy baza_danych wraz z połączeniem a każdy model byłby rozszerzeniem tej klasy i dziedziczył po niej połączenie z bazą. Wtedy pobranie psa metodą wyglądałoby np. tak:

[PHP] pobierz, plaintext 
class Model_Psy extends Model{
 
private $default_table_name = 'Psy';
 
public function getDogById($id){
   $select = $this->select();
   $select->where('id='.$id);
   return $select;
}
... //inne metody powiązane z tabelą psy
[PHP] pobierz, plaintext 

Warto pamiętać o nazewnictwie i nie wsadzać zbyt dużej logiki aplikacji do modelu.

[cojack]

Jak inicjować obiekt

Ja pierdziele kolejny, http://www.cojack.pl/inicjalizacja-a-inicjacja#comment-141 ogarnijcie się ludzie, proszę Was bardzo.

Ten post edytował cojack 25.07.2010, 22:28:40

[Crozin]

model danych powinien być oparty o założenie jeden model = jedna tabela bazy danych

Model powinien być napisany z założeniem, nie model to nie baza danych.

Sam obiekt Pies najlepiej jakby się w ogóle nie zajmował takimi "pierdołami" jak sprawdzanie czy rzeczywiście istnieje. Jeżeli chodzi o walidację wprowadzanych danych możesz ograniczyć się do sprawdzenia takich rzeczy jak to czy wiek to liczba całkowita z zakresu 1-20 albo czy data urodzenia to obiekt typu DataTime. Jednakże obiekt sam w sobie może przechowywać informację o tym czy istnieje on już w bazie (ta informacja jest użyteczna dla samego Modelu by był wstanie przykładowo określić czy przy zapisie wykonać INSERT czy UPDATE (w przypadku RDBMSów)).

Tworzenie obiektów typu Pies z bazy danych pozostawiłbym osobnemu obiektowi (ja je sobie nazywam Repozytoriami). Może on mieć metodę retrieveOne, która na podstawie ID zwraca odpowiedni obiekt:

[PHP] pobierz, plaintext 
interface EntityInterface {
  public function persist();
}
 
class Dog implements EntityInterface {
  protected $name;
  protected $age;
 
  protected $persist = false;
 
  // gettery/settery
}
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
public function retrieveOne($id) {
  // wykonanie zapytania do bazy danych
  $dog = new Dog();
  $dog->setName('Azor')->setAge(4);
 
  $dog->persist(true);
 
  return $dog;
}
[PHP] pobierz, plaintext 

[Staszek27]

Crozin, ja myślałem o czymś takim, tylko nie wiem czy jest sens powoływania całego zbioru po to by wygrzebać jeden obiekt? Z drugiej strony, w rzeczywistości, nawet gdy sięgam po jeden znaczek, to muszę wpierw otworzyć klaser… tak mi przyszło na myśl po tym co napisałeś… Dziękuję za odpowiedź!
Pilsenerze, ja za bardzo nie rozumiem jak Twoja propozycja ma działać w przypadku dwóch niezależnych modeli (czy szerzej: klas)? Połączenie nie zostanie zdublowane!? Również dziękuję za odpowiedź?

[jarexx]

A ja jeśli nie używam frameworka korzystam z metod statycznych.

Do połączenia z bazą klasa Connection ze statyczną metodą getConnection()

[PHP] pobierz, plaintext 
class Connection
{
  private static $DbConnect;
  private function __construct() {}
 
  public static function getConnection()
  {
      if(empty(self::$DbConnect))
      {
          self::$DbConnect = mysql_connect("host","username","haselko");
          mysql_select_db("nazwabazy", self::$DbConnect) or die ("Brak bazy<BR>\n" . mysql_error());
      }
      return self::$DbConnect;
  }
}
[PHP] pobierz, plaintext 

Teraz przykladowa klasa Dog. Konstruktor jako parametr potrzebuje id_dog, a nastepnie statyczna metoda getDog() pobiera sobie z bazy dane psa i przypisujemy je potem do własciwości

[PHP] pobierz, plaintext 
class Dog
{
	protected $id_dog;
	protected $name;
 
    public function __construct($id_dog)
    {
     $data = Database::getDog($id_dog); 
	 $this->id_dog = $id_dog;
	 $this->name = $data['NAME'];
    } // end func
 
	//tu klasycznie -settetery i gettery
 
} // end class
[PHP] pobierz, plaintext 

Dla wygody zawsze używam sobie oddzielnego pliku do obsługi zapytań do bazy.

[PHP] pobierz, plaintext 
class Database
{
    public static function getDog($id_dog)
    {
        $m = "SELECT `ID`, `NAME` FROM DOGS WHERE ID=".$id_dog."";
        $result = mysql_query($m, Connection::getConnection()) or die ("$m<BR>\n" . mysql_error());
        return mysql_fetch_assoc($result);
 
    } // end func
 
	public static function getDogs()
	{
	    $m = "SELECT ID FROM DOGS";
	    $result = mysql_query($m, Connection::getConnection()) or die ("$m<BR>\n" . mysql_error());
	    while($aw = mysql_fetch_assoc($result)) {
	    $tab[] =new Dog($aw['ID']);
	    }
	    return $tab;
	} // end func
 
} // end class
[PHP] pobierz, plaintext 

I teraz gdy np. chce pobrac dane konkretnego psa to robie po prostu

[PHP] pobierz, plaintext 
$dog = new Dog($_POST['id_dog']);
echo $dog->getName();
[PHP] pobierz, plaintext 

Mogę też w prosty sposób pobrać np. wszystkie psy w formie tablicy obiektów typu Dog

[PHP] pobierz, plaintext 
$dogs = Database::getDogs();
if ( is_array($dogs) && sizeof($dogs) ) {
foreach ( $dogs as $obj ) {
echo $obj->getName().'<br />';
}
}
[PHP] pobierz, plaintext 

Dla mnie to bardzo wygodne rozwiązanie, choć pewnie ma bardzo wiele minusów.

[Crozin]

Dla mnie to bardzo wygodne rozwiązanie, choć pewnie ma bardzo wiele minusów.

Jeden podstawowy błąd - zrobiłeś z klasy Connection paskudną "klasę globalną" i zamiast przekazywać jej instancję do obiektów (typu Dog) pobierasz ją z ich wnętrza, teraz:

Spróbuj zmienić nazwę tej klasy.
Spróbuj sprawić by Dog mógł działać na Danych z bazy albo z innego źródła.
Spróbuj użyć tego kodu w innym projekcie.
Spróbuj na tym tak na prawdę wygodnie pracować.

Każda z tych i kilku innych czynności wymaga teraz zmiany w klasach: Dog, Cat, Bird, Bear, itd.