¿Dónde debe ubicarse la lógica de negocios al usar Doctrine 2 y Zend Framework

Question

Tengo una pregunta relacionada con Doctrine 2 y Zend Framework.

Si usa Zend Framework sin Doctrine, de forma predeterminada coloca la lógica comercial en los modelos. Pero como Doctrine 2 tiene Entidades, ¿dónde debería ubicarse la lógica de negocios?

Primero creé modelos donde el administrador de entidades hacía llamadas a las Entidades. Pero cuando quería escribir pruebas unitarias para mis modelos sin llamadas a la base de datos. Necesitaba mover el administrador de entidades a los controladores. Pero obtengo lógica comercial en mis controladores, lo cual no es bueno.

El código siguiente muestra una parte de una acción del controlador:

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

Puede alguien decir cuál es la mejor práctica para este problema? Thx

Answer 1

No estoy seguro de que haya una mejor práctica acordada, pero veo muchas conversaciones sobre las Capas de servicio cuando hablo de Doctrine o Zend Framework.

Cuando comencé mi aplicación con Doctrine, traté de construir tanta funcionalidad en mis objetos Entity como pude, pero rápidamente me di cuenta de que es casi imposible sin inyectar el Entity Manager, lo que rompe totalmente la idea de no persistencia -Aware: objetos que hacen que Doctrine 2 sea tan agradable.

Si viene de un mundo de Active Record, es fácil pensar en su 'modelo' como un solo objeto que corresponde a una tabla de base de datos y que los controladores tienen que hablar con estos objetos. Esto generalmente está bien para aplicaciones CRUD muy simples. Pero debido al enfoque de Doctrine, hacerlo de esa manera es extraño y frustrante.

En su lugar, piense en las diferentes capas de su aplicación. Doctrine es una capa que se encuentra en la parte superior de la base de datos, sus entidades se sientan encima de Doctrine, y su capa de servicio debe situarse encima de sus entidades. Ese paquete completo es su M en MVC, y comprende tanto persistencia de datos como lógica de negocios.

Sugeriría que revise este presentation sobre el tema.

ACTUALIZACIÓN

Originalmente perdí la parte donde se menciona que tenía objetos de modelos separados para realizar llamadas a las Entidades. Creo que sería un patrón aceptable de usar. Si desea escribir pruebas sin hacer llamadas a la base de datos, probablemente querrá usar un simulacro de Entity Manager; es una dependencia sin importar en qué capa lo haya insertado.

Answer 2

Aquí está el esqueleto github proyecto que utilicé, hizo la inicialización de la doctrina 2 con Zend Franework 1.11.2 en el bootstrap, agradable y limpio, usando el modelo para el repositorio de modelo de entidades & para lógica de negocios. La unidad prueba & ant script script también para los desarrolladores de TDD que hay.

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