Dove dovrebbe essere posizionata la logica aziendale quando si utilizza Doctrine 2 e Zend Framework

Question

Ho una domanda relativa a Doctrine 2 e Zend Framework.

Se si utilizza Zend Framework senza Doctrine, per impostazione predefinita si inserisce la logica di business nei modelli. Ma come Doctrine 2 ha Entità dove dovrebbe essere collocata la logica aziendale?

Prima ho creato modelli in cui il gestore di entità ha effettuato chiamate alle entità. Ma quando volevo scrivere test unitari per i miei modelli senza chiamate al database. Avevo bisogno di spostare l'entity manager sui controller. Ma ho una logica di business nei miei controller che non va bene.

Il codice seguente mostra una parte di un'azione di controllo:

 $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(); 

Qualcuno può dire che cosa è la pratica migliore per questo problema? Thx

Answer 1

Non sono sicuro che ci sia una best practice concordata, ma vedo parlare molto dei livelli di servizio quando si discute di Doctrine o Zend Framework.

Quando ho iniziato la mia app con Doctrine, ho cercato di costruire il più funzionalità nei miei oggetti entità come ho potuto, ma subito capito che è quasi impossibile senza l'iniezione di Entity Manager, che rompe totalmente l'idea di pianura, non la persistenza -oggetti che rendono Doctrine 2 così bello.

Se provieni da un mondo Active Record, è facile pensare al tuo 'modello' come singolo oggetto che corrisponde a una tabella di database e che i controller devono parlare con questi oggetti. Questo di solito è ok per applicazioni CRUD molto semplici. Ma a causa dell'approccio di Doctrine, farlo in quel modo è strano e frustrante.

Invece, pensa ai diversi livelli nella tua applicazione. Doctrine è un livello che si trova in cima al database, le tue Entità si trovano in cima a Doctrine e il tuo livello di servizio deve stare in cima alle tue Entità. L'intero pacchetto è il tuo M in MVC e comprende sia la persistenza dei dati sia la logica di business.

Ti suggerisco di dare un'occhiata a questo presentation sull'argomento.

UPDATE

Originariamente ho perso la parte in cui è menzionato avevi oggetti del modello separati effettuare le chiamate alle Entità. Penso che sarebbe uno schema accettabile da usare. Se vuoi scrivere dei test senza effettuare chiamate al database, probabilmente vorrai usare una simulazione dell'Ente Manager - è una dipendenza indipendentemente dal livello in cui lo hai inserito.

Answer 2

Ecco lo scheletro di github progetto che ho usato, ha fatto l'inizializzazione di doctrine 2 con Zend Franework 1.11.2 nel bootstrap, bello e pulito, usando il modello per le entità repository & per la logica di business. Unit test & script di form di ant troppo per voi sviluppatori TDD là fuori.

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