MVC grandes sitios web, use un controlador ... o muchos?

Question

Tengo un sitio bastante grande, y estoy buscando la forma más eficiente de gestionarlo (es el único programador).

Estoy tratando de diseñar una estructura MVC muy simple (no quiero usar un framework) para mantener todo mi código en orden.

Para un sitio enorme, ¿es mejor tener un solo controlador para manejar todas las páginas, o es mejor y más fácil dividirlas?

Si solo una, ¿cuál es un buen ejemplo de un controlador que no es de marco?

Answer 1

Me gustaría dividir las divisiones lógicas en diferentes controladores - si se trata de todas las páginas estáticas, luego se sirve con el mismo controlador de "página estática".

Si tiene algunas páginas estáticas, una página de preguntas frecuentes (o sección), una lista de productos, use un controlador para cada sección diferente. Entonces, las páginas estáticas se extraerían de archivos planos o de una base de datos por un controlador, las páginas de preguntas frecuentes se generarían a partir de una tabla de preguntas frecuentes por otro controlador, los productos y la información se generarían independientemente de la fuente.

Cada vez que se genera una página o se accede a los datos, utilice un controlador diferente.

Por supuesto, la herencia de clase se puede usar para crear la clase base con el código necesario para cualquier controlador.

No estoy seguro de lo que quiere decir con un controlador que no es de marco. Compruebo Zend (gasp) 'Framework', el patrón MVC e incluso el controlador en sí mismo, puede utilizarse aparte del resto del framework.

Answer 2

Normalmente, las personas dividen los controladores en controladores centrados en áreas específicas de funcionalidad.

Luego colocan un "controlador frontal" delante de todo, por lo que solo hay un punto de entrada a la aplicación. El único trabajo del controlador frontal es enrutar las solicitudes entrantes al controlador apropiado.

Mire la configuración del componente Zend_Controller. Puede proporcionar todo lo que necesita y puede usarlo sin tener que comprar Zend Framework completo.

Answer 3

Depende del funcionamiento de las otras piezas. Si solo tiene un archivo de modelo, probablemente no valga la pena dividir el controlador. Si puede dividir el modelo en secciones y en el controlador, hágalo.

Sin embargo, a menudo encuentro que hay demasiada superposición entre los modelos para separarlos. Es posible que tenga un modelo para artículos, pero si desea mostrar los 20 artículos principales en una barra lateral en otras páginas, ese código debe estar en el modelo del artículo, y lo va a necesitar en cada página.

Honestamente, la única manera de hacerlo es probarlo y ver. Comience con un solo punto de entrada, y si también se vuelve difícil de manejar, vuelva a configurarlo en trozos más pequeños.

Answer 4

Un enrutador/despachador, muchos controladores serían mi consejo. Los controladores deben asignar a las URL, lo que significa funcionalidad diferente. Un controlador colaborará con diferentes servicios para lograr cada caso de uso, por lo que un controlador para toda su aplicación se volverá demasiado difícil de manejar si su aplicación tiene más de un puñado de casos de uso.

Answer 5

Tiendo a dividir los controladores según su responsabilidad en una sección específica de un sitio/aplicación. Esto hace que mantener el código sea mucho más fácil. Además, agrupo controladores (y vistas, modelos) dentro de módulos (carpetas). He aquí un ejemplo de un proyecto en el que estoy trabajando en:

• Blog
• Mensajes
• Comentarios
• Categorías
• Ajustes
• Mensajes
• usuarios

Cuanto más complejo es un sitio, más módulos uso. Aunque la mayoría de mis módulos solo contienen un controlador 'Index', me gusta la organización que ofrecen.

Luego uso un enrutador (controlador frontal) que asigna un URI de estilo REST al módulo/controlador/acción adecuado. Por ejemplo: mysite.com/blog/posts/view/7 llamaría Controller_Posts :: view (7) desde el módulo "blog". Un beneficio adicional de usar módulos es que puedo tener URI más específicos que si no tuviera módulos. Aunque supongo que podría remediarse usando un enrutador que permita definir rutas personalizadas, pero no me gusta demasiado.

Como muchas otras cosas, se reduce a lo que te hace sentir cómodo como desarrollador, pero probablemente podamos estar de acuerdo en que cuanto más organización tengas, mejor te sentirás, siempre y cuando no compliques demasiado las cosas .

Como un aparte rápido, le recomendaría que estudie el uso de un marco. Entiendo que no quieras utilizar uno de los que ya existen, ya que también los evité. Terminé escribiendo el mío que durante el año pasado me ha servido muy bien. Fue una gran experiencia de aprendizaje y solo contiene lo que I desea/necesita. Una vez dicho esto, es posible que desee examinar Kohana y CakePHP: no están excesivamente hinchados de la OMI y definitivamente le ahorrarán tiempo si decide no escribir el suyo.