Witam,

Mam pytanie odnośnie DAO (Data Access Object). Mam projekt, w którym obecnie korzystam z Doctrine ale może się to zmienić. W późniejszym czasie może zaistnieć sytuacja gdzie będę pobierał dane przez SOAP, json bądź csv. Chciałbym stworzyć warstwę abstrakcji dostępu do danych gdzie w kontrolerach nie będę musiał się zastanawiać czy korzystać z doctrine, json czy csv. W googlach znalazłem tylko to https://github.com/fightmaster/dao.

Jak wy radzicie sobie z tym problemem ?
Pozdrawiam.

Niestety nie ma zbyt dobrze utartych standardów w tym zakresie, a większość FW/bibliotek/ogólnie kodu w sieci bardzo często utożsamia warstwę biznesową/modelu z ORM-em/bazą danych.
Przygotuj odpowiedni zestaw interfejsów, które w żaden sposób nie są powiązane ze źródłem danych, przykładowo:

[PHP] pobierz, plaintext 
namespace My\Project\Model;
 
// obiekty domeny
interface ArticleInterface {
  function getId();
  function getAuthor();
  function getTitle();
}
 
interface UserInterface {
  function getId();
  function getUsername();
}
 
// dao/repozytoria
interface ArticleDao {
  function persist(ArticleInterface $article);
  function update(ArticleInterface $article);
}
 
interface ArticleRepsitory {
  function find();
  function findOne($pk);
 
  function findByAuthor(UserInterface $author);
  function findByCategory(CategoryInterface $category);
  function findByDateRage(DateTime $from, DateTime $to);
}
 
// faktyczne usługi, z których mógłbyś korzystać wew. kontrolerów
interface ArticleManager {
  function publish(ArticleInterface $article, UserInterface $publisher);
  function doSth(ArticleInterface $article);
}
 
interface ArticlePromotionManager {
  function promoteArticle(ArticleInterface $article, DateInterval $duration);
}
[PHP] pobierz, plaintext 

Konkretna implementacja jest już w pewnym sensie nieistotna.

W tym celu powinno używać się klas abstrakcyjnych z sufiksem Model:

[PHP] pobierz, plaintext 
namespace Acme\DemoBunldle\Model;
 
abstract class UserModel
{
    /**
     * @return string imię
     */
    abstract public function getName();
 
    /**
     * @param string $name imię
     *
     * @return User bieżąca instancja
     */
    abstract public function setName($name);
 
    /**
     * @return string nazwisko
     */
    abstract public function getLastName();
 
    /**
     * @param string $lastName nazwisko
     *
     * @return User bieżąca instancja
     */
    abstract public function setLastName($lastName);
 
    /**
     * @return string imię i nazwisko
     */
    public function getFullName() {
        return $this->getName() . " " . $this->getLastName();
    }
 
    /**
     * @param string $fullName imię i nazwisko
     *
     * @return User bieżąca instancja
     */
    public function setFullName($fullName) {
 
        if (!preg_match('#^[a-Z]+ [a-Z]+$#', $fullName)) {
            throw new \InvalidArgumentException();
        }
 
        list($firstName, $lastname) = split(" ", $fullName, 1);
 
        $this->setName($firstName);
        $this->setLastName($lastName);
 
        return $this;
    }
}
[PHP] pobierz, plaintext 

Implementacja:

[PHP] pobierz, plaintext 
namespace Acme\DemoBundle\Entity;
 
use Acme\DemoBunldle\Model\UserModel;
 
class User extends UserModel
{
    // wygenerowane przez Doctrine
}
[PHP] pobierz, plaintext 

W kontrolerach oraz serwisach oczywiście wymagamy klasy UserModel i nie obchodzi nas skąd gettery biorą dane

Należy pamiętać, że możemy rozszerzać tylko jedna klasę abstrakcyjną podczas gdy interfejsów można implementować wiele do jednej klasy.

Dzięki wielkie za odpowiedź.

Myślałem, żeby zrobić serwis, który by mi zwracał odpowiedni serwis np UserManager, ArticleManager. W pliku konfiguracyjnym bym mógł ustawić z czego korzystam (doctrine, csv, yml, soap, itp). W kontrolerze mógłbym wywoływać serwis:

[PHP] pobierz, plaintext 
/** @var UserManager */
$userManager = $this->get('dao.manager')->get('user');
$userManager->find($id);
[PHP] pobierz, plaintext 

W metodzie get klasy DaoManager jako 2 parametr moglibyśmy ustawiać z jakiego źródła pobierać. Jeśli nie został przekazany to default`owo źródło jest takie jak ustawiliśmy w pliku konfiguracyjnym.

Czy brzmi to w miarę logicznie ?
Pozdrawiam.

Brzmi logicznie ale wydaje mi się, że jest to o jeden serwis za dużo. Możesz po prostu zmieniać klasę serwisu poprzez parametr:



Parametr acme.user_menager.class możesz zmienić w pliku parameters.yml, bądź w klasie Extension parsując config. DI w sf2 pozwala uniknąć właśnie takich konfiguracyjnych obiektów i po to został stworzony.

A ja bym to zrobił nieco inaczej...

Wątpię abyś chciał modyfikować wywołania swoich metod w każdym miejscu gdzie już istnieją... Pomyślałbym o zastosowaniu adapterów opartych o jeden interface. Przy takim podejściu logika wywołująca metodę getUser() zawsze zwróci usera, nie zależnie który adapter został wybrany. Jak dla mnie to najprostrze i zarazem optymalne gdyż jeżeli zmiana w strukturze danych nastąpi, to modyfikujesz jedno miejsce - dany adapter.

Robiłem coś podobnego przy okazji pisania pobierania informacji o użytkowniku logującym się przez Facebook/Linkedin/Google+ etc. Nie zależnie który serwis, zawsze używasz tej samej metody, oczywiście co się dzieje po drodze to już Twoja sprawa.


Pozdrawiam