Wo sollte die Geschäftslogik platziert werden, wenn Doctrine 2 und Zend Framework verwendet werden

Question

Ich habe eine Frage zu Doctrine 2 und Zend Framework.

Wenn Sie Zend Framework ohne Doctrine standardmäßig verwenden, platzieren Sie Geschäftslogik in den Modellen. Aber wie Doktrin 2 hat Entitäten, wo sollte die Geschäftslogik platziert werden?

Ich hatte zuerst Modelle erstellt, in denen der Entity Manager Aufrufe an die Entitäten machte. Aber wenn ich Komponententests für meine Modelle ohne Datenbankaufrufe schreiben wollte. Ich musste den Entity Manager auf die Controller verschieben. Aber ich bekomme Geschäftslogik in meinen Controllern, was nicht gut ist.

Der folgende Code zeigt einen Teil eines Aktions Controller:

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

jemand sagen kann, was für dieses Problem die beste Praxis ist? Thx

Answer 1

Ich bin mir nicht sicher, ob es eine vereinbarte Best Practice gibt, aber ich sehe viel über Service Layer, wenn ich über Doctrine oder Zend Framework spreche.

Als ich meine App mit Doctrine startete, versuchte ich, so viel Funktionalität wie möglich in meine Entity-Objekte zu integrieren, erkannte aber schnell, dass dies fast unmöglich ist, ohne den Entity Manager zu injizieren, was die Idee der reinen Nicht-Persistenz völlig durchbricht - Objekte, die Doctrine 2 so schön machen.

Wenn Sie aus einer Active Record-Welt kommen, ist es leicht, sich Ihr 'Modell' als einzelnes Objekt vorzustellen, das einer Datenbanktabelle entspricht und mit dem Controller kommunizieren müssen. Dies ist normalerweise für sehr einfache CRUD-Anwendungen in Ordnung. Aber aufgrund von Doctrines Ansatz ist es seltsam und frustrierend, es so zu machen.

Denken Sie stattdessen an die verschiedenen Schichten in Ihrer Anwendung. Lehre ist eine Schicht, die oben auf der Datenbank sitzt, Ihre Wesen sitzen oben auf Lehre, und Ihre Service-Schicht sollte auf Ihren Wesen sitzen. Dieses ganze Paket ist Ihr M in MVC und es umfasst sowohl Datenpersistenz als auch Geschäftslogik.

Ich würde vorschlagen, überprüfen Sie diese presentation zu diesem Thema.

UPDATE

ich das Teil ursprünglich verpaßt, wo Sie erwähnen Sie die Entität Anrufe separate Modellobjekte hatten. Ich denke, das wäre ein akzeptables Muster zu verwenden. Wenn Sie Tests schreiben möchten, ohne Datenbankaufrufe zu machen, werden Sie wahrscheinlich einen Mock des Entity Managers verwenden wollen - es ist eine Abhängigkeit, egal auf welcher Ebene Sie sie einfügen.

Answer 2

Hier ist das GitHub-Skelett Projekt ich verwendet, es hat die Doktrin 2 Initialisierung mit Zend Franework 1.11.2 im Bootstrap, schön und sauber, mit Modell für Entitäten & Modell Repository für Business-Logik. Unit-Tests & Ameise bauen Skript auch für Sie TDD-Entwickler da draußen.

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