Siema,
pisze do was z następującym problemem... zastanawiam się czy we dopuszczalne jest uzycie repozytorium w encji, (chodzi mi o metode setProfil)

[PHP] pobierz, plaintext 
class UserEntity
{
   //jakies atrybuty
 
   //jakies metody
 
   /** @var ProfilEntity */
  private $_oProfil;
 
   public function addProfil(ProfilEntity $oProfilEntity)
   {
       $this->_oProfil  = $oProfilEntity;
   }
 
   public functin getProfil()
   {
        if(!isset($this->_oProfil)
       {
              return $this->setProfil();
       }
       else
       {
              return $this->_oProfil;
        }
   }
 
 
   private function setProfil()
   {
         $oProfilRepository = new ProfilRepository;
 
         return $oProfilRepository->find();
   }
 
 
}
 
class ProfilEntity
{
     //jakies atrryburty i metody
}
 
[PHP] pobierz, plaintext 

Czy powinienem odwoływac się do repozytorium z poziomu encji czy raczej przeslać obiekt (wykorzystujac metode addProfil). Jak wy robicie?

Jest to dopuszczalne, aczkolwiek powinieneś to repozytorium przekazać do obiektu jak każdą inną zależność - poprzez wstrzyknięcie.

Inna sprawa, że w DDD bardzo ważne jest podejście Design By Contract i - w idealnym świecie programisty - zależność tego repozytorium powinna być zapodana jako interfejs.

A jak powinno wyglądać tworzenie encji dla kolekcji userow . Czy powinienem pobrać tablice danych w jednym zapytaniu joinem i na podstawioe nich stworzyc encje czy tworzyc kilka osobnych zapytań, np.:

1) zapytanie z joinem

[PHP] pobierz, plaintext 
class UserRepository
{
    //jakies atrybuty i metdody
 
    public function findAll()
    {
         $aRows = $_usersDAO->findAll();  //zwraca uerow z profilami
         $aContener = array();
        foreach($aRows as $row)
        {
             $aUser  = array('id' => $row['id'],
                                     'imie'       => $row['imie'],
                                     'nazwisko' => $row['nazwisko'],
                                     'profil_id'   =>  $row['profil_id']
                                    );
 
             $oUserEntity = new UserEntity($aUser);
 
             $aProfil = array('id'       => $row['profil_id'],
                                    'telefon' => $row['telefon'],
                                    'email'   => $row['email']
                                   );
 
             $oUserEntity->addProfil(new ProfilEntity($aProfil));
 
             $aContener[] = $oUserEntity;
        }
 
        return new UserCollection($aContener);
    } 
 
}
[PHP] pobierz, plaintext 

2) zwykly select

[PHP] pobierz, plaintext 
class UserRepository
{
    //jakies atrybuty i metdody
 
    public function findAll()
    {
         $aRows = $this->_usersDAO->findAll(); //zwraca userow
         $aContener = array();
        foreach($aRows as $row)
        {
             $aUser  = array('id'          => $row['id'],
                                     'imie'       => $row['imie'],
                                     'nazwisko' => $row['nazwisko'],
                                     'profil_id'   =>  $row['profil_id']
                                    );
 
             $oUserEntity = new UserEntity($aUser);
 
             $oProfilEntity = $this->_oProfilRepository->find($row['profil_id'])
 
             $oUserEntity->addProfil($oProfilEntity);
 
             $aContener[] = $oUserEntity;
        }
 
        return new UserCollection($aContener);
    } 
 
}
 
 
class ProfilRepository
{
    //jakies atrybuty i metody
 
    public function find($id)
    {
        $aRow = $this->_oProfilDao->find($id);
 
        return new ProfilEntity($aRow);
    }
 
}
[PHP] pobierz, plaintext 

3) tworze kolekcje userow bez pobierania profilu i dopiero w widoku gdy wyswietlam userow wywoluje metdoe (z pierwszego postu) getProfil, ktora zwroci mi obiekt Profil.

4) jakieś inne rozwiązanie?

Nie myślałeś nad wykorzystaniem Doctrine2 jako warstwy DAO? Architektura projektu pasuje idealnie do Twojego w dodatku oszczędziło by Ci to masę pracy.

Co do tego czy wykonać zapytanie SELECT z JOIN-em czy SELECT + n SELECT-ów. W zdecydowanej większości przypadków to pierwsze - bo będzie to po prostu wydajniejsze. To ostatnie możesz stosować np. w przypadku gdy pobierasz kolekcję 10 użytkowników, którą wyświetlasz jako jakąś listę ale dla przykładowo pierwszego elementu tej listy pozna nazwą użytkownika wyświetlasz też jakieś dane z jego profilu. Generalnie możesz poszukać sobie pod frazą "fetch eager lazy" - powinieneś znaleźć sporo materiałów bo jest to dosyć popularne zagadnienie.

Zastosowanie Doctrine na pewno pomogłoby w uzyskaniu efektu o który mi chodzi ale nie pomogłoby mi w zaspokojeniu ciekawości . Chciałbym się dowiedzieć jak rozwiązuje się taki problem (poza tym w tym projekcie nie moge zastosować Doctrine).

Pierwsze podejście to tzw. "eager fetching" czyli pobranie wszystkiego zawczasu. Jeżeli wiesz że będziesz potrzebować obiektu UserProfile dla (niemalże) każdego obiektu User powinieneś zastosować tą metodę.
Drugie podejście jest niemalże z definicji złe.
Trzecie podejście to tzw. "lazy fetching" czyli dobieranie obiektu UserProfile na żądanie (w momencie wywołania User::getProfile()). Przydatne gdy obiektu UserProfile będziesz potrzebować dla bardzo nielicznych obiektów User z całej kolekcji.

Jak już wcześniej powiedziałem więcej na temat obu metod znajdziesz w sieci.

Teraz to ja muszę zaspokoić ciekawość. Dlaczego?

Projekt, który odziedziczyłem jest spitolony. I jest to duzy projekt wciaz rozwijany (chociaz mam nadzieje, ze dazy ku koncowi! ) i zastosowanie Doctrine nie jest chyba najlepszym wyjsciem (a taki mix nie bylby wesoly). Zreszta Doctrine 2 pracuje na php 5.3 a serwis jest na serwerze php 5.2.


Dotychczas pobrane dane byly przekazywane bezposrednio do widoku w postaci tablicy. Ma to moze swoje plusy (jest wydajniejsze niz tworzenie wpierw obiektow) ale czy zgodne z OOP? Moim zdaniem powinno pracowac sie na obiektach.