Witam. Chciałbym trochę rozwinąć myśl NoiseMC. Bo Twoje podejście mnie lekko zaintrygowało.

Rozumiem że wynika ono z modelu MVC ?

Mam pytanie odnośnie tego co napisłeś.
Jak skorelowac ze sobą konkretny obiekt Model i nie-Model ?
Chodzi mi o to, że jeżeli utworzę dwie klasy to bede mial 2 obiekty. Jezeli Data Object ma przechowywać tylko dane, to rozumiem, że nie powinien on mieć wogóle metod manipulującymi danymi ? Nawet gettery ?

Załużmy taką sytuację.
pobieram z bazy Artykul. Chcialbym zmienic mu opis i zrobic update danych na bazie.
Czy dobrze rozumiem, ze klasa Data Access Objects zajmuje sie pobieraniem danych i zwracaniem obiektu a po poprawieniu przekazuje obiekt to Data Access Objects i go zapisuje ?
Chyba ze umiescic go w klasie model na stale. No nie wiem.

Np. Mam taką klase

[PHP] pobierz, plaintext 
<?php
class ArticleInfo() {
 
 var $id;
 var $title;
 var $info;
 var $oAuthor;
 
 function __construct ($id=null, $title=null, $info=null, Author $author=null) {
  $this->id=$id;
  $this->title=$title;
  $this->info=$info;
  $this->oAuthor=$author;
 }
 
 function getTitle() {
  return $this->title;
 }
}
 
 
class ArticleInfo_Model($oDB) {
 
 var $oDB;
 
 function getArticleInfoById($id) {
   $sQ="SELECT *
   FROM articles
   WHERE id_article=?";
 
  $aArticle=$this->$oDB->getRow($sQ, array($id));
 
  if (!is_null($aArticle) {
   $modelAuthor=new Author_Model($this->oDB);
   $oAuthor=$modelAuthor->getAuthor($aArticle['authorid');
   return new ArticleInfo($id, $aArticle['title'], $aArticle['info'], $oAuthor);
  }
 }
}
 
class Author() {
 
 var $id;
 var $firstname;
 var $lastname;
 var $email;
 var $login;
 var $password;
 
 function __construct($id=null, $firstname=null, $lastname=null, $email=null, $login=null, $password=null) {
  $this->id=$id;
  $this->firstname=$firstname;
  $this->lastname=$lastname;
  $this->email=$email;
  $this->login=$login;
  $this->password=$password;
 }
 
 function getId() {
  return $this->id;
 }
 
 function getFirstName() {
  return $this->firstname;
 }
 
 
}
 
class Author_Model($oDB) {
 
 var $oDB;
 
 function getAuthor($id) {
 
  $sQ="
  SELECT * FROM author WHERE id_author=?
  ";
 
  $aAuthor=$this->$oDB->getRow($sQ, array($id));
 
  if (!is_null($aAuthor) {
   return new Author($id, $aAuthor['firstname'], $aAuthor['lastname'], $aAuthor['email'], $aAuthor['login'], $aAuthor['password']);
  }
 }
}
?>
[PHP] pobierz, plaintext 

i teraz wykorzystanie

[PHP] pobierz, plaintext 
<?php
$oDB=new DB();
 $oDB->connect(DSN);
 
 $html=new Smarty();
 
 $modelArticleInfo=new ArticleInfo_Model($oDB);
 $oArticleInfo=$modelArticleInfo->getArticleInfoById(34);
 
 $html->assign("article",$oArticleInfo);
?>
[PHP] pobierz, plaintext 

W ten sposób wyciągam dane konkretnego artykułu (po jego ID).
I co o tym myslicie ? Czy to jest prawidłowo ?

Czy moglbym stworzyc np.
klasę Articles_Model, ktora zawieralalby metody zwracajace:
1. obiekt ArtykulInfo (class ArticleInfo)
2. obiekt Artykul (class Article)
3. lista info artykulow danej kategorii -> tablica obiektow class ArticleInfo

Data Access Object - zwraca i zapisuje obiekty. Może (chociaż nie musi) nadzorować zarządzanie transakcjami bazodanowymi.

Model w rozumieniu MVC to dane, chociaż wraz z przejściem do PHP pojęcie to zostało wypaczone. Teraz wszystko co zwraca tablice i odwołuje się do bazy to model. Nie panowie - model w podejściu obiektowym to z pewnością nie jest tablica. Zamiast modelu powinien występować duet Domain Object (zachęcam do przeczytania mojej noty na ten temat) oraz DAO. Teraz jak to wygląda - obiekty mają wewnątrz powiązania a DAO jest fasadą dostępu do obiektów - innymi słowy DAO zwraca już obiekty danego typu. Nas, z perspektywy użytkowników interfejsu to w ogóle nie interesuje - po prostu dajemy ID dostajemy obiekt. Pod spodem może być XML, baza danych, plik tekstowy, wszystko, z czego da się wyłuskać dane. Zyskujemy w ten sposób jednolitą definicję obiektów biznesowych w pełni niezależną od źródła danych. "Obiekty" mogą współpracować niezależnie od miejsca pochodzenia - nic nie stoi na przeszkodzie by odczytanego z XML autora wrzucić do książki, którą mamy w bazie, ponieważ DAO bazując na definicji obiektów bez problemu to wszystko zapisze.
Poniżej przedstawiam przykład napisany "na szybko".

[PHP] pobierz, plaintext 
<?php
/**
 * Umowny interfejs dla zapisywanych obiektów.
 **/
interface Persistable {
	function getId();
}
 
/**
 * Definicja wspólnych metod dla wszystkich data-access-object'ów.
 **/
interface GenericDAO {
 
	// pobranie pojedynczego rekordu
	function getById(int $id);
 
	// zapisanie - wstawienie bądź aktualizacja
	function save(Persistable $object);
 
	// usunięcie rekordu
	function remove(Persistable $object);
}
 
/**
 * Metody specyficzne dla autora.
 **/
interface ArticleDAO extends GenericDAO {
 
	// pobranie książek po autorze.
	function getByAuthor(int $id);
 
}
 
// implementacja bazowa
abstract class GenericDAOImpl implements GenericDAO {
 
	// obsługiwany typ 
	private $className;
 
	public function __construct($className) {
		$this->className = $className;
	}
 
	// nazwa obsługiwanego typu
	protected final function getClassName() {
		return $this->className;
	}
 
	// pobranie po identyfikatorze
	protected abstract function findById(int $id);
 
	// zapisanie obiektu
	protected abstract function doSave(Persistable $id);
 
	// usunięcie obiektu
	protected abstract function doRemove(Persistable $id);
 
	protected final function verify(Persistable $obj) {
		if (!($obj instanceof $this->getClassName()) {
			throw new DAOException('Unexpected type ' . get_class($obj)
				 . ', expected ' . $this->getClassName());
		}
	}
 
	// pobranie pojedynczego rekordu
	public final function getById(int $id) {
		return $this->findById($id);
	}
 
	// zapisanie - wstawienie bądź aktualizacja
	public final function save(Persistable $object) {
		verify($object);
		return $this->doSave($object);
	}
 
	// usunięcie rekordu
	function remove(Persistable $object) {
		verify($object);
		return $this->doRemove($object);
	}
}
/**
 * Implementacja DAO dla baz danych.
 **/
class SQLGenericDAO extends GenericDAOImpl {
 
	// zwraca Persistable
	protected abstract function hydrate(array $data);
 
	protected function buildSelect(int $id, $table = null) {
		if (is_null($table)) {
			$table = strtolower($this->getClassName()) ;
		}
		return 'select * from ' . $table . ' where '. $table .'_id = ' . $id;
	}
 
	protected function execute(string $sql) {
		// tutaj jakiś kod związany z wykonaniem zapytania.
 
		if ($resultSize > 1) {
			// dla wszystkich wierszy tworzymy obiekty
			foreach ($pers as $k => $v) {
				$pers[$k] = $this->hydrate($v);
			}
		} else {
			$pers = array($this->hydrate($row));
		}
		return $pers;
	}
 
	// pobranie po identyfikatorze
	protected final function findById(int $id) {
		$pers = $this->execute($this->buildSql($id));
		if (!isset($pers[0])) {
			throw new ObjectNotFoundException($this->getClassName(), $id);
		}
		verify($pers[0]);
		return $pers[0];
	}
 
	// zapisanie obiektu
	protected function doSave(Persistable $object) {
		return $this->insert($this->getClassName(), $object);
	}
 
	// usunięcie obiektu
	protected function doRemove(Persistable $object) {
		// Persistable ma zawsze określone ID.
		return $this->delete($this->getClassName(), $object->getId());
	}
}
 
// i wreszcie nasza implementacja ... 
class AuthorSQLDAO extends SQLGenericDAO implements AuthorDAO {
 
	public function __construct() {
		parent::__construct('Author');
	}
 
	protected function hydrate(array $row) {
		 $author = new Author($row['author_id']);
		 $author->setName($row['author_name']);
		 // etc...
		 return $author;
	}
 
		// w pośpiechu źle zrobiłem tą metodę - można skorzystać do tego z getById..
	public function getByAuthor(int $id) {
		$pers = $this->execute($this->buildSql($id)); // tu powinniśmy dostać tablicę
 
		foreach ($pers as $obj) {
			verify($obj);
		}
 
		return $pers;
	}
}
 
// a może inna wariacja... ?
abstract class AuthorXMLDAO extends XMLGenericDAO implements AuthorDAO {}
?>
[PHP] pobierz, plaintext 

przyjmując ze dopiero zaczynam OOP - to co napisales to dla mnie jakaś ciezka abstrakcja

ale przeanalizuje o co w tym kodzie chodzi. dzieki ogromne.

Dobrze, klika słów wyjaśnienia do kodu powyżej.

Persistable to interfejs. Potrzebujemy go by móc stworzyć generyczne DAO posługujące się minimalną ilością danych, stąd wymagamy tylko identyfikatora. Nazwa klasy to nazwa naszej tabelki. Jest to uproszczone założenie, ale w razie czego można sobie podmapować nazwy klas do nazw tabel w bazie danych.


GenericDAO ponownie interfejs. Posłuży on nam do stworzenia bazowego DAO. Wszystkie obiekty, które obsługujemy możemy ogólnie rzecz biorąc odczytać, zapisać i usunąć. To jest własnie to DAO nie określamy w nim jeszcze żadnego zachowania z poszczególnym źródłem danych a tylko zapewniamy bardzo, bardzo ogólną definicję.

ArticleDAO jest to interfejs rozszerzający GenericDAO. Powiedzmy, że jest coś co powoduje, że chcemy odczytać autorów korzystając z innego pola niż ID - na przykład roku urodzenia. Wtedy tworzymy metodę getAuthorsByAge($age). W tym momencie wszystkie implementacje DAO dla autorów powinny zatroszczyć się o dostarczenie odpowiednich metod.

GenericDAOImpl klasa abstrakcyjna w której zasadniczon weryfikujemy tylko typ obiektu. Ze względu na to, że PHP nie wspiera typów generycznych (szablonów) pojawia się metoda verify. Wyrzuca ona wyjątek gdy typ przekazanego w argumencie obiektu nie zgadza się z typem jaki ma obsługiwać dana instancja DAO. Poza weryfikowaniem danych nie ma tu nic więcej ot, delegowanie metod by obiekty zawsze były weryfikowane (final przy implementacjach metodach zdefiniowanych w GenericDAO).

SQLGenericDAO abstrakcyjna klasa zbudowana w oparciu o GenericDAOImpl, która zapewnia podstawowe operacje związane z bazą danych - odczyt, generowanie prostych zapytań SQL i tak dalej. Jest to pierwszy z poziomów, który związany jest z konkretnym źródłem danych. Na bazie tej klasy możemy tworzyć sobie już specyficzne implementacje AuthorSQLDAO, BookSQLDAO, CategorySQLDAO i tak dalej. Wszystko co wymagamy od implementacji to dodanie metody hydrate, która stworzy z wiersza bazy danych obiekt oraz przekazanie nazwy klasy jaką chce to DAO obsługiwać (odwołanie do parent::__construct to w gruncie rzeczy konstruktor GenericDAOImpl).

XMLGenericDAO to tylko pomysł by pokazać, że możemy zbudować w oparciu o GenericDAOImpl klasę, która może bez problemów odczytywać dane z innego źródła danych. Tu również pojawiła by się metoda hydrate, która by tworzyła obiekty na bazie danych z XML (przekształcenie DOMElement w jakiś charakterystyczny obiekt).

AuthorSQLDAO ostatni węzeł naszej hierarchii zapewniający odczyt autorów z bazy danych. Pojawia się w nim troszkę mylna implementacja metody getByAuthor z interfejsu AuthorDAO. Chciałem tu pokazać użycie tego co nam zapewnia implementacja SQLGenericDAO - odczyt danych to tylko proste odwołania do metod.

AuthorXMLDAO no to też czysta abstrakcja - coś analogicznego do w/w DAO, które by się sprowadziło do implementacji paru metod.

Jeśli macie pytania, sugestie, wątpliwości, zapraszam do rozmowy. Razem uda nam się dojść do konsensusu .

wiesz co. lekko skumałem o co ci chodzi w takim podejsciu.
niemniej ja zakladam, ze system, ktory pisze bedzie oparty o baze mysql i nie przewiduje trzymania danych np. w plikach xml.

Natomiast jest to dosc ciekawe. Np. mozna zastosowac ten mechanizm podczas tworzenia np. jakiegos prostego CMS'a,
ktory bedzie umozliwial zapisywanie danych wg. wyboru (pliki proste, baza mysql, itd).

To nad czym teraz pracuje to serwis ala interia360.pl (no na pwno nie ta skala).
Generalnie jest
1. Uzytkownik (czytelnik, autor)
2. Kategoria i podkategoria
3. Artykul
4. Wstep artykulu (lista takich wstepow jest generowana dla kazdej kategorii i podkategorii)
5. Lista komentarzy artykulu.
6. komentarz.


Kazdy artykul mozna ocenic po zalogowaniu 1 raz. Kazdy artykul ma zliczana ilosc czytań.

Zaczalem pisac proceduralnie i mialem juz troche kodu naklepane ale stwierdzilem, ze jednak lepiej w koncu nauczyc sie OOP.
Mysle ze dziedzina serwisu doskonale sie do tego nadaje.

Niemniej interfejsy i abstakcje to jeszcze dla mnie za wysoko.

Bo widzisz, to co zaproponował mi NoiseMC powoduje ze mam wiele pytań. To co proponujesz Ty to juz straszna abstakcja za którą niemniej jestem bardzo wdzięczny, bo naprawde nie domyslalem sie ze mozna to tak zorganizowac. Jest to bardzo logiczne i pewnie z czasem doszedlbym do tego. Ale po co sie domyslac jak mozna sie zapytac. Splatch - twoj blog dodalem do ulubionych
Pytań miałbym bardzo, bardzo duzo ale jednak chcialbym juz zaczac to pisac

To po prostu użyj Propela - szkielet prostego serwisu zrobisz w kilka godzin i zapomnisz, czym są zapytania SQL .

Pozdrawiam.

uzycie propela nie bedzie oznaczalo ze naucze sie myslec w sposob obiektowy na poziomie jaki prezentuje splatch.
a chce sie tego nauczyc.

@Cysiaczek wszyscy dobrze wiemy, że Propel nie jest złotym środkiem, a w przypadku DAO nie ma problemu by wykorzystać ORM. Wystarczy nam przecież obiekt, który bez większych problemów da się zapisać. Problem w tym, że Propel dorzuca swoje metody etc, nie wspiera obiektów lekkich, przeźroczystych i to utrudnia wykorzystanie go do tworzenia warstwy domenowej. Jakkolwiek przy odrobinie wysiłku dało by się. Dla zainteresowanych - w aplikacjach opartych na Springu mimo wykorzystania potężnego narzędzia jakim jest bez wątpienia Hibernate, tworzy się interfejsy oraz ich implementacje, które dopiero pod spodem korzystają z tego co oferuje ORM.

Spójrzmy na klasę DaoSupport:
afterPropertiesSet() - walidacja danych
checkDaoConfig() - walidacja konfiguracji
initDao() - inicjowanie DAO

Następnie mamy do dyspozycji rozszerzenia dla różnych bibliotek. Od ogólnych implementacji - JPA poprzez Hibernate i Toplink po SqlMap (iBatis) i JDBC (czytaj natywne zapytania).
CciDaoSupport, HibernateDaoSupport, JdbcDaoSupport, JdoDaoSupport, JpaDaoSupport, SqlMapClientDaoSupport, TopLinkDaoSupport.

Wierz mi, że nieprzypadkowo te klasy trafiły do Springa - we większości projektów opartych na tym frameworku, które widziałem do tej pory na oczy, występuje dao dla ORM oraz JDBC. Wynika to z tego, że część operacji po prostu nie jest przepychana przez narzędzia mapujące a przez zapytania. Powiedzmy, spore partie danych są wrzucane przez masowe inserty, ponieważ użycie zasobów przez ORM zabiło by serwer aplikacyjny.

Podobnie moi drodzy ma się sprawa z naszymi przyszłymi projektami. Warto sobie budować "core", który bezproblemowo przechodzi z jednego projektu do drugiego by w przyszłości zaoszczędzić czas. Pojawił się tu temat Springa - jest to narzędzie bardzo popularne wśród developerów Javy, momentami aż za bardzo, aczkolwiek skala jego wykorzystania wynika z tego, że jest on bardzo łatwy w adaptacji. Gdy dobrze skonstruujesz sobie abstrakcję przy DAO będziesz mógł je użyć wszędzie - niezależnie od projektu i użytych bibliotek.

Become to co zaproponowalem to jest najprostsza implementacja modelu o ktorym pisze Splatch i byc moze dobry piewszy krok w kierunku myslenia obiektowego.
To co zaproponowal Splatch to bardzo zaawansowana implementacja z wykorzystaniem interfejsow i klas abstrakcyjnych, dobrze byloby gdybys to tez rozumial aczkolwiek na poczatek i gdy pracujesz nad projektem sam moze nie bedziesz musial sie na niej wzorowac. Interfejsy i klasy abstrakcyjne przydaja sie w momencie kiedy projekt staje sie duzy i pracuje nad nim kilka lub kilkanascie osob, za ich pomoca kontrolujesz porzadek w systemie i narzucasz innym developerom jak ma wygladac API systemu tak, aby wszsytko wygladalo tak jak zaplanowal sobie architekt, zeby nie bylo samowolki i zeby system byl spojny.

Swoja droga tez nie jestem biegly w projektowaniu systemow i widze dzieki Wam ze moje myslenie idzie w dobra strone Ciesze sie ze poruszylismy ten temat.

Nawiazujac jeszcze do kodu Become, zastanawiam sie czy obiekty pomocnicze, ktore zawieraja obiekty DO powinny byc tworzone przez DAO na podstawie id i przypisywane do DO czy tez DO powinien sobie tworzyc je sam korzystajac z ich DAO.

Dla przykladu zarzuce:

Data Object

[PHP] pobierz, plaintext 
<?php
class Offers_Offer
{
	public function __construct ($offerID, $urlSlug, $abbreviation, $name, $isFirst)
	{
		$this->offerID = $offerID;
		$this->urlSlug = $urlSlug;
		$this->abbreviation = $abbreviation;
		$this->name = $name;
		$this->isFirst = $isFirst;
 
		$headerImageModel = new Offer_Header_Model ();
		$this->headerImage = $headerImageModel->getHeaderImageByOffer ($this);
 
		$contentPagesModel = new Offer_Content_Model ();
		$this->contentPages = $contentPagesModel->getContentPagesByOffer ($this);
 
		$metaTagsModel = new Offer_Meta_Model ();
		$this->metaTags = $metaTagsModel->getMetaTagsByOffer ($this);
	}
 
}
?>
[PHP] pobierz, plaintext 

Data Access Object

[PHP] pobierz, plaintext 
<?php
class Offer_Model extends Base_Model
{
	public function __construct ()
	{
		$offerList = $this->aycAccess->getSchoolList ();
 
		foreach ($offerList as $offer)
		{
			$this->offerList[$offerID] = new Offer_Offer ($offer['schoolID'], $offer['url_slug'], $offer['abbrev'], $offer['school_name'], $isFirst);
		}
	}
}
?>
[PHP] pobierz, plaintext 

Moze inaczej.

Spróbujmy zrobić na przykładzie takiej funkcjonalności.
Nie traktujcie tego że chcę iść na łatwiznę i szukam gotowców. Znajomy, który pracuje w gratka.pl polecił mi nauke na przykładach
Wiec próbuje stworzyć takie przykłady.

Aby było jak najprościej przyjmijmy ze nie stosujemy interfejsów i klas abstakcyjnych.

Załóżmy że chcemy mieć następujące obiekty.

1. ArtykulWstep (pola: artykul_id, tytul, wstep)
2. Artykul (pola: autor, artykul_id, tytul, wstep, tresc)
3. Autor (id, imie,nazwisko)

oraz chcielibyśmy uzyskać konkretny artykuł po jakimś ID oraz listę artykulWstep z danej kategorii.



Przede wszystkim.

[PHP] pobierz, plaintext 
<?php
 
class Autor_DO {
 
 var $id;
 var $imie;
 var $nazwisko;
 
 function __construct($id=null, $imie=null, $nazwisko=null) {
  $this->id=$id;
  $this->imie=$imie;
  $this->nazwisko=$nazwisko;
 }
}
 
class Autor_SQL_DAO {
 
 var $DB;
 
 function __construct($DB=null) {
  if (is_null($DB)) return null;
  $this->DB=$DB;
 }
 
 function getAutorById($id=null) {
  if (is_null($id)) return null;
  $sql="
  SELECT *
  FROM autor
  WHERE autor_id=?
  ";
 
  $aRes=$this->DB->getRow($sql, array($id));
  if (is_array($aRes) and count($aRes)==1) {
   return new Autor_DO($aRes['autor_id'], $aRes['imie'], $aRes['nazwisko']);
  }
  return null;
 }
}
 
class ArtykulWstep_DO {
 
 var $artykul_id;
 var $tytul;
 var $wstep;
 
 function __construct($id=null, $tytul=null, $wstep=null) {
  $this->artykul_id=$id;
  $this->tytul=$tytul;
  $this->wstep=$wstep;
 }
}
 
class Artykul_DO extends ArtykulWstep_DO {
 
 var $oAutor;
 var $tresc
 
 function __construct($id=null, $tytul=null, $wstep=null, $tresc=null, Autor_DO $autor=null) {
  $this->tresc=$tresc;
  $this->oAutor=$autor;
  parent::__construct($id, $tytul, $wstep);
 }
}
 
class Artykul_SQL_DAO {
 
 var $DB;
 
 function __construct($DB) {
  $this->DB=$DB;
 }
 
 function getArtykulById($id=null) {
  if (is_null($id)) return null;
  $sql="
  SELECT *
  FROM artykul
  WHERE artykul_id=?
  ";
 
  $aRes=$this->DB->getRow($sql, array($id));
  if (is_array($aRes) and count($aRes)==1) {
   $autor_sql_dao=new Autor_SQL_DAO($this->DB);
   $oAutor=$autor_model->pobierzAutora($aRes['autor_id']); // obiekt autor
   return new Artykul_DO($aRes['artykul_id'], $aRes['tytul'], $aRes['wstep'], $aRes['tresc'], $oAutor);
  }
  return null;
 }
 
 /*
  Zwraca obiekt ArtykulWstep_DO
 */
 function getArtykulWstepById($id=null) {
  if (is_null($id)) return null;
  $sql="
  SELECT *
  FROM artykul
  WHERE artykul_id=?
  ";
 
  $aRes=$this->DB->getRow($sql, array($id));
  if (is_array($aRes) and count($aRes)==1) {
   return new ArtykulWstep_DO($aRes['artykul_id'], $aRes['tytul'], $aRes['wstep']);
  }
  return null;
 }
 
 /* 
  Zwraca tablice obiektow ArtykulWstep_DO z kategori o podanym ID
 */
 function getListaArtykulowWstepByCategoryId($id=null) {
  if (is_null($id)) return null;
  $sql="
  SELECT *
  FROM artykul
  WHERE kategoria=?
  ";
 
  $aRes=$this->DB->getAll($sql, array($id));
  if (is_array($aRes) and count($aRes)>=1) {
   for ($i=0; $i<count($aRes); $i++) {
	$aoArtykulyWstep[$i]=new ArtykulWstep_DO($aRes['artykul_id'], $aRes['tytul'], $aRes['wstep']);
   }
   return $aoArtykulyWstep;
  }
  return null;
 }
}
?>
[PHP] pobierz, plaintext 

co o tym myslicie ? Czy jako początkujacy w OOP moglbym tak to zrobic ?

wlasnie sobie tak mysle, czy klasa User_DAO nie powinna rozszerzać możliwosci klasy DO ?

czyli byloby:

[PHP] pobierz, plaintext 
<?php
class User {
 
}
?>
[PHP] pobierz, plaintext 

i

[PHP] pobierz, plaintext 
<?php
class User_DAO extends User {
}
?>
[PHP] pobierz, plaintext 

Bo naprawde, jezeli rozdziele te dwie klasy, to jak mam operowac na danych obiektu.
Zalozmy taka sytuacje. Uzytkownik po zalogowaniu chce zmienic swoje dane osobowe.
klasa User_DAO zwraca obiekt User z danymi. Przekazuje te dane do formularza. Po ich sprawdzeniu dane te chce zapisac.
To gdzie powinny trafic dane z formularza ? Do obiektu User, czy do obiektu User_DAO, a może do obiektu User, a obiekt User przekazać do obiektu User_DAO, który zapisze dane do bazy.
Normalnie chyba jednak powinienem najpierw robic jak najprościej, bo siedze juz 3 godziny nad klasa Authentication i User i co chwile zmieniam koncepcje.

No ja sobie tworze obiekt DO i przekazuje go do DAO:

[PHP] pobierz, plaintext 
<?php
class ProductsController
{
	public function saveAction ()
	{
		$productID = (int)$this->request->getParam ('id');
 
		$product = new Products_Product ();
 
		$postData = $this->request->getPost ();
 
		if (! empty ($postData))
		{
			$product->productID = $productID;
			$product->name = $postData['name'];
			$product->urlSlug = $postData['urlSlug'];
			$product->copy = $postData['copy'];
 
			$this->productsModel->save ($product);
		}
	}
}
?>
[PHP] pobierz, plaintext 

Pominalem tutaj walidacje i filtrowanie danych wejsciowych ale to zupelnie inny temat

Nie, nie powinna. Nie wpychaj dziedziczenia tam gdzie jest ono zbyteczne. Przed stworzeniem hierarchii pomyśl co wspólnego mają klasy. Często przykładem dla pokazania dziedziczenia są relacje rodzice - dzieci czy też pojazd - auto. W Gdyby przełożyć dziedziczenie UserDAO z User na świat rzeczywisty mielibyśmy twierdzenie, że słoń jest potomkiem bloku mieszkalnego..

NoiseMC.

Widze ze controler tez masz stworzony jako klasę.
Ja do tej pory mialem kontroler zbudowany tak, ze ładowałem odpowiedni plik php na podstawie parametru, ktory okreslal kontroler, a funkcja z kontrolera byla wybierana na podstawie paraemtru funkcji.
np. jezeli w adresie bylo /?c=user&f=commisionlist

to w index.php ładowałem główny plik kontrolera czyli user.php
tam mialem switch po parametrze $_GET['f'] i wtedy w
case 'commisionlist' wykonywały się reszta operacji.

ja na razie staram sie przynajmniej wprowadzic obiekty do danych. niemniej podoba mi sie Twoje podejscie.
Kontroler jako klasa i w kontrolerze tworzone sa obiekty DAO i obiekty DA. Zapewne w contolerze rowniez tworzysz obiekty weryfikujace dane.

Mozesz zdradzic czy twoj sposob utworzenia logiki kodu jest gdzies opisany w jakiejsc ksiazce, bo nie ukrywam ze bardzo mi sie podoba.
Moglbys cos polecic co warto przeczytac ? A moze moglbys podzielic sie jakims wiekszym kodem lub wskazac jaki soft jest podobnie napisany, ktory jest ogolnie dostepny. chetnie bym cos takiego przeanalizowal ?

Inna sprawa ze czytam sobie PHP5 Zaawansowane programowanie i tam pisza, że klasa DataManager powinny byc statyczne. Czy DataManager to DAO ? Pisze tez, że nie powinno się umieszczac obiektu w innym obiekcie, ale tworzyc tzw. Kolekcje.

Oj ludzie im bardziej wnikam w OOP tym bardziej mnie ono przeraza

No ja sie sugeruje tym co jest opisane tutaj i tutaj i co pisza ludzie na forum oraz korzystam z Zend Framework