¿Un controlador por página o muchas páginas en un controlador?


16

Solo quería un consejo sobre la forma de hacer las cosas de MVC. Estoy usando codeigniter y me preguntaba si es mejor tener un controlador por página para un sitio web o tener un controlador para todas las páginas.

Digamos que tengo un sitio web simple donde puedes visitar la página de inicio, iniciar sesión, crear una cuenta y contactar al administrador.

  1. ¿Sería mejor tener estos controladores: frontend (index), inicio de sesión, cuenta, contacto O tener un controlador llamado frontend o lo que sea con las acciones como login, createAccount, contact?

  2. ¿Cuándo sabe si es mejor usar un controlador en una situación?


Siempre he vivido según el credo: un controlador para gobernarlos a todos y, en la oscuridad, vincularlos. (En realidad no, pero me gusta cómo suena. :-)
Peter Rowell

Respuestas:


17

Es mejor tener un controlador por unidad lógica, por ejemplo, AccountController (inicio de sesión, registro), PagesController (inicio, contacto), Backend -> PagesController (crear, editar, eliminar), UsersController (crear, editar, eliminar), etc.


¿Cómo representaría un sitio web con estas áreas: inicio, inicio de sesión, cuenta, contacto? ¿Usarías 2 controladores como tu ejemplo? si va a localhost / abre el controlador del hogar, entonces si va a localhost / contact en teoría, ¿no debería ir al controlador de contacto? ¿Y qué quieres decir con backend?
Rushino

Depende de cuál sea la estructura de las páginas y cuántas páginas tenga. Haré HomeController (inicio, contacto) o PagesController (inicio, contacto O detalles (id)). Por ejemplo, en ASP.NET MVC tiene HomeController predeterminado con la página Inicio y Acerca de.
Santas

Me gusta este metodo. También un ClientController (o como quiera llamarlo) para Acciones llamadas a través de Jquery.Ajax que no son específicas de ninguna parte particular de su aplicación. es decir, reutilizable desde cualquiera de sus puntos de vista
Chris

Parece la respuesta correcta para mí. CodeIgniter acepta subdirectorios para controladores que permiten separar los controladores en zonas para que pueda terminar con dos páginas de controlador (uno por zona). ¡Gracias!
Rushino

¿Pero no terminarías con Controladores algo grandes, a pesar de que sus acciones son todas relativas? ¿O es que no hay problema?
Kid Diamond

4

@Rushino Aquí tienes dos 'aplicaciones': la interfaz (para lectores) y la de fondo (para administradores). Para cada grupo de funcionalidad, tiene un controlador.

Iniciar sesión es un grupo de este tipo, que incluye la generación del formulario HTML (los campos, llamar a la vista) y el manejo del formulario (la validación, la conexión con el modelo). Entonces 'login' es un controlador con dos acciones: generateForm y handleForm.

Las páginas se dividen entre la aplicación front-end, que solo muestra páginas, y la aplicación back-end que permite editar, eliminar, crear y posiblemente verlas de una manera diferente. La página de inicio es 'solo otra página' en la parte frontal al menos, por lo que cabe dentro del controlador de páginas. En el backend, su lógica podría ser lo suficientemente diferente como para justificar tener un controlador completamente diferente.

Para los usuarios: si los usuarios pueden registrarse ellos mismos, necesitarán un controlador frontend, pero si no, todo lo que tiene que ver con los usuarios simplemente va en el backend.

Tenga en cuenta que cada una de las funciones de back-end puede requerir un generador y un controlador. Sin embargo, estas cosas se pueden dividir en archivos de configuración, con un complemento que es un generador de formularios genérico.

En resumen, se ve así:

Frontend
  Pages
    View, Handle
  Login
    View, Handle
  Users
    Register (note that the handler can be the same as 'create' on the backend)
  Contact
    View
    Handle

Backend
  Users
    Create, Delete, Edit, Update, View
  Pages
    Create, Delete, Edit, Update, View

Espera ... ¿estás diciendo que una sección representa una aplicación? forma interesante de hacerlo (y probablemente LA forma de hacerlo). Me pregunto si codeigniter lo hace de esta manera ... lo comprobará. Debo asegurarme de que puede pasar de una aplicación a otra sin interrumpir ninguna sesión o estado de conexión.
Rushino

1
@Rushino CodeIgniter puede hacerlo de esta manera: puede colocar carpetas dentro del directorio Controladores. La distinción entre 'aplicaciones' no está en el nivel de base de datos / modelo, sino en el nivel de controlador / vista. La razón de la separación es que su backend está haciendo cosas muy diferentes, a menudo con un diseño completamente diferente. Ayuda con la seguridad, ya que puede restringir IP todo el directorio de fondo. Y ayuda con el desarrollo porque puedes trabajar en el backend sin afectar la interfaz.
Dan Blows

2

Creo que debería usar un controlador por unidad de negocio, como OrdersController para todas las operaciones relacionadas con pedidos y demás. Soy consciente de que en este caso, los controladores se ENORMES, pero aún podemos usar clases auxiliares para delegar cosas como la inicialización del modelo y las clases parciales para distribuir acciones en archivos separados.

Por ejemplo, puedo tener Create.cs and OrdersControllerarchivos OrdersController List.cs para la clase OrdersController, cada uno con el conjunto correspondiente de acciones. Hace las cosas mucho más limpias y aún mantiene las operaciones de pedidos centralizadas en una sola clase de controlador.

Solo mis 2 centavos.


0

Creo que podría adoptar un enfoque diferente:

Un controlador principal como puerta de entrada que entrega solicitudes a controladores específicos. De esta manera, podría usar este controlador frontal para verificar cosas comunes como la autenticación de usuarios, analíticas de Google y cualquier otra cosa general que le gustaría hacer y mantener la estructura MVC pura.

Esta no es mi idea, pero Symfony Framework funciona de esta manera, así que puedo decirte que, según mi experiencia, esta es una forma realmente agradable y elegante de implementar una interfaz.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.