Data Objects i Data Access Objects Opcje

[become]

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

Ten post edytował become 30.11.2007, 12:44:08

[Cysiaczek]

To po prostu użyj Propela - szkielet prostego serwisu zrobisz w kilka godzin i zapomnisz, czym są zapytania SQL (IMG:http://forum.php.pl/style_emoticons/default/haha.gif) .

Pozdrawiam.

[splatch]

To po prostu użyj Propela - szkielet prostego serwisu zrobisz w kilka godzin i zapomnisz, czym są zapytania SQL (IMG:http://forum.php.pl/style_emoticons/default/haha.gif) .

@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.