Gdzie powinna być umieszczona logika biznesowa podczas używania Doctrine 2 i Zend Framework

Question

Mam pytanie związane z Doctrine 2 i Zend Framework.

Jeśli używasz Zend Framework bez Doctrine domyślnie umieszczasz logikę biznesową w modelach. Ale jak Doctrine 2 ma Entity, gdzie powinna być logika biznesowa?

Najpierw stworzyłem modele, w których podmiot zarządzający podmiotem wykonywał połączenia z podmiotami. Ale kiedy chciałem napisać testy jednostkowe dla moich modeli bez wywołań bazy danych. Musiałem przenieść zarządcę jednostki do kontrolerów. Ale dostaję logiki biznesowej w moich kontrolerach, co nie jest dobre.

Poniższy kod przedstawia część działania kontrolera:

 $customerAddress = $this->_model->save($values, $id); 

     $this->_em->persist($customerAddress); 

     // Update default billing address 
     $defaultBilling = $this->_model->saveDefaultBilling($values, $customerAddress); 
     if ($defaultBilling != FALSE) { 
      $this->_em->persist($defaultBilling); 
     } 

     // Update default shipping address 
     $defaultShipping = $this->_model->saveDefaultShipping($values, $customerAddress); 
     if ($defaultShipping != FALSE) { 
      $this->_em->persist($defaultShipping); 
     } 

     $this->_em->flush(); 

Może ktoś powiedzieć co jest najlepsze praktyki dla tego problemu? Thx

Answer 1

Nie jestem pewien, czy istnieje uzgodniona najlepsza praktyka, ale podczas dyskusji na temat Doctrine lub Zend Framework widzę wiele dyskusji dotyczących Warunków Usług.

Kiedy zacząłem swoją aplikację z Doctrine, starałem się jak najwięcej wbudować w moje obiekty Entity, ale szybko zdałem sobie sprawę, że jest to prawie niemożliwe bez wstrzyknięcia Entity Manager, co całkowicie łamie ideę zwykłego, nietrwałości - o obiektach, które czynią Doktrynę 2 tak ładną.

Jeśli pochodzisz ze świata Aktywnych Rekordów, łatwo jest pomyśleć o twoim "modelu" jako pojedynczym obiekcie, który odpowiada tabeli bazy danych, a kontrolerzy muszą rozmawiać z tymi obiektami. Zazwyczaj jest to w porządku w przypadku bardzo prostych aplikacji CRUD. Ale ze względu na podejście Doctrine, robienie tego w ten sposób jest dziwne i frustrujące.

Zamiast tego pomyśl o różnych warstwach w aplikacji. Doctrine jest warstwą, która znajduje się na szczycie bazy danych, twoje jednostki znajdują się na szczycie Doctrine, a twoja warstwa serwisowa powinna znajdować się nad Twoimi jednostkami. Ten cały pakiet jest twoim M w MVC i obejmuje zarówno trwałość danych, jak i logikę biznesową.

Proponuję sprawdzić to presentation na ten temat.

UPDATE

początkowo brakowało część, gdzie wymieniony miał oddzielne obiekty Modelarstwa połączeń podmiotom. Myślę, że byłby to dopuszczalny wzór do zastosowania. Jeśli chcesz pisać testy bez wywoływania baz danych, prawdopodobnie będziesz chciał użyć makiety menedżera encji - to zależność bez względu na to, w którą warstwę ją umieścisz.

Answer 2

Oto szkielet Github W projekcie użyłem inicjalizacji doktryny 2 przy pomocy Zend Franework 1.11.2 w bootstrapie, ładnie i czysto, używając modelu dla repozytoriów modelu dla logiki biznesowej. Testy jednostkowe & skrypt budujący mrówki także dla ciebie, programistów TDD.

https://github.com/eddiejaoude/Zend-Framework--Doctrine-ORM--PHPUnit--Ant--Jenkins-CI--TDD-