¿Este código es insano?

Question

Estoy siguiendo un tutorial que creo que está escrito por alguien que no sabe lo que hace (ya descubrió 2 errores obvios y el resto del código es complicado). Pero no quiero desacreditar al tipo por completo, así que estoy preguntando sobre algo más que no entiendo.

En primer lugar, voy a enviar 100 puntos brownie, mis 2 mascotas, y una caja de bombones a el que me puede explicar lo que es pasando con este código.

Él está utilizando la arquitectura basada en módulos. El nombre del módulo es frontmodule. El módulo tiene MVC. Y el módulo tiene un interno library propio.

/modules/  
     /frontmodule/ 
      /models/ 
      /views/ 
      /controllers/  -- the /module controller is here (undestandable) 
      /library/    
      /Controller/  -- the /module/library controller is here (why?!) 
       /Action/ 

Primero viene el confundir parte. Por qué cada módulo tiene una biblioteca interna y por qué esa biblioteca intencional tiene su propia controllers y actions. ¿Es esta una mejor práctica? Estoy pensando que esta biblioteca podría moverse a un complemento que el módulo pueda usar. No estoy seguro ..

Ahora viene la parte interesante .... además de que cada módulo tiene su propia biblioteca interna, también hay una biblioteca común compartido por todos los módulos (ver a continuación al mismo nivel de carpetas que /modules) y que la biblioteca común también tiene sus propios controladores y acciones (al igual que cada uno de bibliotecas internas tienen sus propios controladores y acciones)

/modules 
    /library/ 
     /Common/ 
      /Controller/   -- the /common/library controller is here (why?!) 
       /Action/ 
        /Helper/ 
       /Plugin/ 

por lo que tenemos 3 controladores:

• el módulo controlador
• el controlador de la biblioteca interna del módulo
• el controlador de la biblioteca común

Ahora aquí está la loco parte que creo que es complicar la vida

Él dice: A mo El controlador dule amplía el controlador principal de biblioteca del módulo , que también amplía el controlador de biblioteca común .

class IndexController 
     extends Frontoffice_Library_Controller_Action_Abstract { ... } 

abstract class Frontoffice_Library_Controller_Action_Abstract 
     extends Custom_Controller_Action_Abstract { ... } 

así que supongo:

• el controlador del módulo = IndexController
• el controlador de la biblioteca interna del módulo = Frontoffice_Library_Controller_Action_Abstract
• el controlador de la biblioteca común = Custom_Controller_Action_Abstract

donde module controller se extiende module internal library's controller

y module internal library's controller extiende common library's controller

alguien ha visto algo como esto antes? Supongo que este código no será fácil de mantener, pero quizás los que tengan más experiencia con Zend puedan decirme qué es lo que este tipo intenta lograr. La estructura de la aplicación es un poco demasiado desordenada. Creo que está abusando de MVC en lugar de usarlo para simplificar la aplicación y su mantenimiento.

Answer 1

Lo mejor de Zend Framework es que es use-at-will, lo que significa que puede usar un solo componente o puede usarlos todos. La mayoría de los componentes también son muy flexibles, ya sea a través de la configuración o la extensión (herencia o composición, con ZF a favor de este último).

Zend Framework MVC es extremadamente flexible ... incluso hasta el punto en que muchos lo han acusado de ser sobre-diseñado o hinchado. Esto es subjetivo

Seguro, probablemente no quiera utilizar Zend Framework para un formulario de contacto simple; sin embargo, no hay nada que le impida utilizar solo Zend_Mail y Zend_Form sin Zend MVC/Application.Teniendo en cuenta la flexibilidad, actualmente no existe una metodología única que se promocione como la mejor en términos de organizar una aplicación en módulos. Esta es una tarea que queda mejor para el implementador.

Esto nos lleva al tutorial en cuestión. El tutorial ha ideado una estrategia para su reutilización. Ésto es una cosa buena; sin embargo, hay algunos defectos con su enfoque.

1. Una biblioteca por módulo. Esto no es necesariamente malo; sin embargo, en la mayoría de los casos no es necesario. Permite explorar qué opciones tenemos en caso de que tal estructura sea necesaria por alguna razón.

   a. Cree una biblioteca general (lo más probable es que ya lo haga) espacio de nombres (pseudo si < 5.3 o espacios de nombres reales si> = 5.3).

   b. Utilice el "Autoloader de Recursos" intrínseco http://framework.zend.com/manual/en/zend.loader.autoloader-resource.html

   NOTA: Personalmente, no he usado mucho el recurso de autocarga. La única vez que lo usé, descubrí que podría haber movido esos artículos a mi biblioteca. Dicho esto, hay usos para esto. Parece brillar cuando esperas mezclar y combinar módulos entre proyectos o para su distribución. ZF2 abordará esto de una manera menos hacky en mi humilde opinión.

2. Controles de base para reutilizar. De nuevo, la reutilización es genial; sin embargo, Zend Framework ofrece mejores alternativas a los controladores de subclasificación (herencia). En primer lugar, aquí hay algunas razones para NO utilizar la herencia del controlador:

   a. Mantener las cosas DRY se ve frustrado cuando tiene varios módulos que difieren lo suficiente como para necesitar una clase base por módulo, pero la funcionalidad se copia/pega a través de la clase de controlador base de cada módulo.

   b. Resulta difícil administrar las propiedades heredadas, ya que es más difícil visualizar qué función heredada está siendo utilizada por cada controlador/acción

   c. Con PHP que permite la herencia de clases único sencillo, se suena la única oportunidad de herencia aquí - usar esto sólo si no hay otras opciones a la izquierda

   Alternativas:

   un. Plug-ins frontales del controlador Utilícelos cuando la funcionalidad/lógica necesite ejecutarse en cada solicitud independientemente del módulo/controlador/acción

   b. Ayudantes de acción Según lo mencionado por el líder del proyecto ZF, "son un mecanismo integrado en Zend Framework que le permite extender sus controladores de acción de una manera que usa composición en lugar de herencia". No hay nada que puedas hacer en un controlador que no puedas hacer a través de un ayudante de acción. Úselos cuando la funcionalidad deba suceder por controlador y/o por acción.

Entonces, ¿fue el ejemplo en el tutorial sobre-diseñado? No necesariamente; sin embargo, es ciertamente un candidato para de ingeniería incorrecta en lo que se refiere a las mejores prácticas y disposiciones dadas por Zend Framework.

Necesito hacer una digresión por un momento y discutir los términos más de la ingeniería y hinchada por un momento

Cuando alguien te dice que algo es más de la ingeniería y/o hinchado sin indicar un contexto, tómelo con un grano de sal.

El artículo de Wikipedia - http://en.wikipedia.org/wiki/Overengineering dice en parte "... cuando un producto es más robusto o complicado que el necesario para su aplicación ...".

Por lo tanto, cuando se hace referencia a algo como uno más de la ingeniería/hinchada debe tener cuidado para calificar el contexto o aplicación a mano. Las declaraciones generales deben tomarse con un grano de sal y en la mayoría de los casos, no tomarse en absoluto. Esto es similar a decir algo como "Nunca usaría una 'Sierra Circular' para carpintería, ya que tiene demasiadas características y esas características me confunden". Claro, esta herramienta puede ser excesiva para proyectos pequeños en el hogar/lado; sin embargo, dado que es súper flexible, te alegrará que tengas esta herramienta cuando te encuentres en situaciones en las que nunca pensaste que te encontrarías.

Sí, más los marcos web son excesivos para una simple aplicación CRUD como una página de contacto o incluso una simple aplicación de blog. Es desafortunado que la mayoría de los marcos web usen el ejemplo del blog como su ejemplo introductorio: vaya figura.

Extra Info:

1. Si quisiera cambiar los diseños basados ​​en el módulo/controlador/acción, se podría escribir un controlador frontal Plug-in. Simplemente llame a "Zend_Layout :: startMvc" y páselo por un nombre de diseño y una ruta.

2. Cambio del script de vista real basado en el Aceptar cabecera (o parámetro de URL o HTTP método de reemplazo X-cabecera) se puede hacer con el ayudante de acción de cambio de contexto (intrínseco a Zend Framework) - http://framework.zend.com/manual/en/zend.controller.actionhelpers.html

3. Siéntase libre de pasar una instancia de modelo a un ayudante de acción. También puede configurar sus ayudantes de acción con configuración desde el arranque. De esta forma, no es necesario almacenar cosas en el registro global, que es solo una variable global glorificada. Esta es una dependencia oculta que no necesitas.Para el mejor reutilización, puede crear sus propios recursos de plug-in personalizados mediante la extensión de Zend_Application_Resource_ResourceAbstract - http://framework.zend.com/manual/en/zend.application.core-functionality.html#zend.application.core-functionality.resource-resourceabstract

Answer 2

Esto es una locura. Estás haciendo páginas web, ¿verdad? Esto no es difícil. Yo diría que las cosas informados es la definición misma de la manipulación excesiva:

http://en.wikipedia.org/wiki/Overengineering

Answer 3

No loco en absoluto. Tal vez mal o demasiado ingeniería, pero podría ser una configuración útil.

Son solo dos niveles "extra" de herencia, que en algunos casos pueden tener perfecto sentido.

• propiedades o métodos que deberían estar disponibles en cada controlador del sistema vaya al "controlador de biblioteca común".
• propiedades o métodos que deberían ser disponible en todos los controladores de un módulo en particular van en el "módulo de controlador de biblioteca interna" -
• propiedades o métodos requeridos por un solo controlador , hormigón, viven en que el hormigón controlador.

Pero, en general, esto sugiere una gran cantidad de lógica en los controladores, que en general es un mal diseño.

Answer 4

De esta manera, puede haber lógica aplicada a:

a) un controlador en particular

b) todos los controladores en un módulo

c) todos los controladores de aplicación