Czy warto stosować PEAR::DB w OOP oraz czy przechowywać dane w tabliczy czy w osobnych zmiennych ? Opcje

[become]

mam taką klasę

[PHP] pobierz, plaintext 
<?php
class Autor() {
 
 var $oDB=null;	# obiekt PEAR:(IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) B;
 var $aAutor=null;  # zmienna przechowujaca dane autora
 
 function Autor($oDB=null) {
  if (!is_null($oDB)) $this->oDB=$oDB;
 }
 
 function dbGetAutorById($id=null) {
 
  if (is_null($id) return null;
 
  $aQ="
   SELECT *
   FROM autor
   WHERE id=?
  ";
 
  $aA=$this->oDB->getRow($sQ, array($id), DB_FETCHMODE_ASSOC);
  if (is_array($aA) and count($aA)==1) $this->aAutor=$aA;
 }
}
?>
[PHP] pobierz, plaintext 

i pozniej sposob wykorzystania tego

[PHP] pobierz, plaintext 
<?php
include "PEAR/DB.php"; 
 
 $oDB=new DB();
 $oDB->connect(DSN);
 
 $autor=new Autor($oDB);
 $autor->dbGetAutorById(234);
?>
[PHP] pobierz, plaintext 

mam pytanie. czy mozna ją tą zbudować ? czy uzycie obiektu klasy PEAR:: DB i przekazanie jej do innej klasy w powyzszy sposob jest prawidlowe ? Czy wogole warto uzywać pakiet PEAR:: DB cyz moze cos innego ?

Drugie pytanie. Czy reprezentawac dane autora jako tablice czy raczej stworzyc osobne zmienne na np. pole imie, nazwisko, email, ktore bedą reprezentowac kolumny w tabeli ?

Ten post edytował become 28.11.2007, 13:22:02

[NoiseMc]

Ja mam osobno Data Objects i Data Access Objects. Data Objects przechowuja tylko dane, a Data Access Objects pobieraja dane z bazy i na ich podstawie zwracaja tablice wypelnionych danymi z bazy Data Objects czyli na przyklad:

[PHP] pobierz, plaintext 
<?php
class Products_Product
	{
		public $productID;
		public $categoryID;
		public $name;
		public $urlSlug;
		public $copy;		
		public $displayOrder;
 
		 public function __construct ($productID = null, $categoryID = null, $name = null, $urlSlug = null, $copy = null, $displayOrder = null
		{
			$this->productID = $productID;
			$this->categoryID = $categoryID;
			$this->name = $name;
			$this->urlSlug = $urlSlug;
			$this->copy = $copy;
			$this->displayOrder = $displayOrder;
		}
	}
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
class Products_Model extends Base_Model 
	{
		public function getAll ()
		{
			$query = 'SELECT * FROM ' . $this->config->database->prefix . 'products ORDER BY DisplayOrder DESC';
 
			$statement = $this->db->prepare ($query);
 
			$statement->execute ();
 
			while ($product = $statement->fetch ())
			{
				$products[] = new Products_Product ($product['ProductID'], $product['CategoryID'], $product['Name'], $product['UrlSlug'], $product['Copy'], $product['DisplayOrder'], $product['MetaTitle'], $product['MetaDescription'], $product['MetaKeywords']);
			}
 
			if (empty ($products))
			{
				return null;
			}
 
			return $products;
		}
			}
?>
[PHP] pobierz, plaintext 

Co do DB to uzywam PDO, ma chyba taka sama funkcjonalnosc jak PEAR:DB, a jest wbudowane w PHP 5 i obiekt DB tworze sobie w klasie bazowej dla Data Access Object:

[PHP] pobierz, plaintext 
<?php
class Base_Model 
	{
		protected $db;
		protected $config;
 
		public function __construct ()
		{
			$this->config = Zend_Registry::get ('config');
 
			$this->db = new PDO ('mysql:host=' . $this->config->database->host . ';dbname=' . $this->config->database->dbname . '', $this->config->database->username, $this->config->database->password);
 
			$this->db->setAttribute (PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
			$this->db->setAttribute (PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, 1);
		}
			}
?>
[PHP] pobierz, plaintext 

Korzystam z tego tak:

[PHP] pobierz, plaintext 
<?php
		$productsModel = new Products_Model ();
	$products = $productsModel->getAll ();
?>
[PHP] pobierz, plaintext 

Jezeli w przyszlosci chcialbym zmienic PDO na PEAR:DB to zmieniam to tylko w klasie bazowej dla modelu ... ewentualnie wyrownuje niespojnosc w API obu bibliotek piszac sobie fasade DB_Adapter ktory korzysta z PEAR:(IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) B ale ma API identyczne jak PDO. Zmiana biblioteki DB odbywa sie bez naruszenia pozostalych klas i tylko w klasie bazowej dla Data Access Objects

Ten post edytował NoiseMc 28.11.2007, 15:12:41

[become]

aaa kumam, czyli proponujesz stworzyc klase reprezentujaca model danych usera oraz osobno klase reprezentujaco sam user.
a klasa model usera bylaby rozszerzeniem klasy bazowej model.

To ma sens jezeli zapytania sformatujesz tak jak napisales, bo np. w PDO nie ma mozliwości stworzenia zapytan tak jak w PEAR:(IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) B (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif)
Np. w PEAR:(IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) B w zapytaniu można stosować znak zapytania, ktory zostaje zamieniony na odpowiednie wartosci z tablicy parametrów, ktorą to tablice przekazujesz do metody np. getAll.
No ale to szczegol.

A jak reprezentowac dane w klasie?

Np. jezeli mam USER'a, który w bazie SQL ma imie, nazwisko, email

To czy lepiej jest w klasie USER utworzyć jedną zmienną, która będzie przechowywać tablice zawierajacą wszystkie informacje na temat usera, czy w klasie stworzyć osbne zmienne dla imie, nazwisko, email i podstawić do nich dane z wyniku zapytania ?

Ten post edytował become 28.11.2007, 15:58:42

[NoiseMc]

Ja jestem za tym zeby kazdy rekord z bazy byl reprezentowany jako obiekt z wlasciwosciami ... jakos tak bardziej mi czysto i ladnie wyglada.
Co do znakow zapytania to pewnie masz na mysli paramertyzowane zapytania ... i tak tez jest to mozliwe w PDO na dwa sposoby, wiecej tutaj: http://de2.php.net/pdo-prepare.

U mnie to wyglada tak:

[PHP] pobierz, plaintext 
<?php
class Products_Model extends Base_Model 
{
	public function save (Products_Product $product)
	{
		$query = 'SELECT MAX(DisplayOrder) AS DisplayOrder FROM ' . $this->config->database->prefix . 'products LIMIT 1';
 
		$statement = $this->db->prepare ($query);
		$statement->execute ();
 
		$result = $statement->fetch ();
 
		$maxDisplayOrder = ++$result['DisplayOrder'];
 
		if (isset ($product->productID))
		{
			$query = 'UPDATE ' . $this->config->database->prefix . 'products SET CategoryID = ?, Name = ?, UrlSlug = ?, Copy = ?, MetaTitle = ?, MetaDescription = ?, MetaKeywords = ? WHERE ProductID = ?';
		}
		else 
		{
			$query = 'INSERT INTO ' . $this->config->database->prefix . 'products (CategoryID, Name, UrlSlug, Copy, MetaTitle, MetaDescription, MetaKeywords, 
DisplayOrder) VALUES (?, ?, ?, ?, ?, ?, ?, ?)';
		}
 
		$statement = $this->db->prepare ($query);	
 
		$statement->bindParam (1, $product->categoryID);		
		$statement->bindParam (2, $product->name);		
		$statement->bindParam (3, $product->urlSlug);
		$statement->bindParam (4, $product->copy);
		$statement->bindParam (5, $product->metaTitle);
		$statement->bindParam (6, $product->metaDescription);
		$statement->bindParam (7, $product->metaKeywords);
 
		if (isset ($product->productID))
		{	
			$statement->bindParam (8, $product->productID);
		}
		else 
		{
			$statement->bindParam (8, $maxDisplayOrder);
		}
 
		$statement->execute ();
 
		if (isset ($product->productID))
		{	
			return $product->productID;
		}
		else 
		{
			return $this->getLastInsertID ();
		}
	}
}
?>
[PHP] pobierz, plaintext 

Ten post edytował NoiseMc 28.11.2007, 16:28:36

[phpion]

Np. w PEAR:(IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) B w zapytaniu można stosować znak zapytania, ktory zostaje zamieniony na odpowiednie wartosci

Poczytaj http://pl.php.net/manual/en/ref.pdo.php w szczególności Example#7 Repeated inserts using prepared statements.

A jak reprezentowac dane w klasie?

Np. jezeli mam USER'a, który w bazie SQL ma imie, nazwisko, email

To czy lepiej jest w klasie USER utworzyć jedną zmienną, która będzie przechowywać tablice zawierajacą wszystkie informacje na temat usera, czy w klasie stworzyć osbne zmienne dla imie, nazwisko, email i podstawić do nich dane z wyniku zapytania ?

Zrób tak jak napisał Ci ~NoiseMC. W klasie User opisz z czego składa się obiekt użytkownika (np. private $login, private $password itd), utwórz konstruktor, dopisz gettery i settery i w zasadzie to tyle (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) Natomiast w UserDb przechowuj statyczne metody pobierające dane z bazy i zwracające obiekty typu User (lub tablice obiektów).

// heh, ciut za późno no ale niech już zostanie (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Ten post edytował phpion.com 28.11.2007, 16:34:03

[NoiseMc]

Wlasnie dobrze ze dodales, jeszcze gettery i settery mozna dopisac do klas Data Objects ale to jest juz zupelnie inny temat. (Przydatnosc getterow i setterow)

[phpion]

(IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Pisanie getterów i setterów może wydawać się upierdliwe i zbędne (można przecież skorzystać z __get() oraz __set() lub po prostu określić składowe jako public (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) ) jednak przynosi wiele korzyści, o których poczytasz w linku podanym przez ~NoiseMC.

Od siebie dodam jeszcze, że podział modelu na User oraz UserDb jest realizowany np. przez Propel'a (komunikacja z bazą zapisana w UserPeer). Dla mnie osobiście takie rozdzielenie modelu na 2 klasy jest jak najbardziej logiczne. Masz klasę reprezentującą dany obiekt oraz klasę do manipulowania nim (Create Retrieve Update Delete).

[Cysiaczek]

Od siebie dodam jeszcze, że podział modelu na User oraz UserDb jest realizowany np. przez Propel'a (komunikacja z bazą zapisana w UserPeer)

Szkoda tylko jednej rzeczy - słabej zarządzalności tą klasą. Nazwa bazy danych i tabeli zapisana na sztywno w stałej. Gdy zmianisz nazwę bazy danych, to automatycznie musisz generować model od nowa - jest to lekko irytujące podczas fazy testowej.

[phpion]

Szkoda tylko jednej rzeczy - słabej zarządzalności tą klasą. Nazwa bazy danych i tabeli zapisana na sztywno w stałej. Gdy zmianisz nazwę bazy danych, to automatycznie musisz generować model od nowa - jest to lekko irytujące podczas fazy testowej.

Fakt, zgadzam się, chodziło mi tylko o rozdzielenie modelu na 2 klasy.

[become]

Widzać, że macie spore pojęcie o OOP. Ja dopiero zacząłem się uczyc. Dzieki za info.

Korzystam z tego tak:

[PHP] pobierz, plaintext 
<?php
		$productsModel = new Products_Model ();
	$products = $productsModel->getAll ();
?>
[PHP] pobierz, plaintext 

no dobra. a czy nie lepiej byloby metody klasy Products_Model stworzyc jako statyczne i wywolywac bezposrednio
z klasy ?

[PHP] pobierz, plaintext 
<?php
 $products = Products_Model::getAll ();
?>
[PHP] pobierz, plaintext 

Rozumiem ze w tym przypadku model produktow stanowi wzorzec fabryki ?