Cuándo crear un nuevo controlador en los rieles

Question

Me pregunto cuándo sabe que necesita crear un controlador en una aplicación de rieles.

Por ejemplo, estoy siguiendo el tutorial en desarrollo web ágil con Rails y la aplicación crea varios modelos, todos con vistas separadas y controladores. Sin embargo, también creamos un controlador de tienda, pero no hay ningún modelo asociado a él. ¿Por qué necesitamos un controlador sin modelo? ¿No podrían los controladores de los modelos manejar todas las operaciones requeridas?

¿Es esto común? Si es así, ¿cómo se determina cuándo algo garantiza un controlador?

Gracias!

---

Estas respuestas ayudan, gracias.

Mi preocupación es que cuando desarrolle algo por mi cuenta, comenzaré a crear controladores inútiles o, por el otro lado, no crearé los controladores necesarios. Pero, supongo que necesito dejar de pensar en controladores y modelos como una relación 1-1, ¿correcto? Si estoy entendiendo correctamente, podría haber muchos controladores accediendo a un modelo y muchos modelos que se utilizan en un controlador?

Answer 1

ACTUALIZACIÓN: Recomiendo leer How DHH Organizes His Rails Controllers , lo cual lo explica mucho mejor que mi respuesta original.

---

Creo que la pregunta sería más adecuado si quiere decirlo de otra manera:

¿Por qué necesitamos el modelo (AR en este caso) para cada controlador?

Y la respuesta, por supuesto, es que no. Cuando piense en los controladores, es mejor no pensar en los datos, sino retroceder un poco, y pensar en los recursos . Si busca REST en internet, encontrará muchos artículos y la mayoría de ellos incluirán varias explicaciones de los términos recurso y representación. Para resumir esta historia, simplifiquemos en exceso y digamos que el recurso es todo lo que vale la pena mencionar. Articles es un recurso (de colección). Store es un recurso (singular, miembro).

Tome la firma en los usuarios, por ejemplo. Probablemente ya tenga UsersController que (de forma predeterminada) le permitirá agregar nuevos usuarios (crear recursos), eliminarlos (eliminar recursos), mostrar usuarios únicos y también a todos los usuarios. Si solo piensa en términos de datos y controladores, probablemente empiece a crear acciones adicionales como login_user en UserController, que es un olor. Si piensa en los recursos, y eso es "todo lo que vale la pena mencionar o crear URI para él", podría pensar que necesita otro recurso, y es: sesiones. Piensa de esta manera: cuando el usuario inicia sesión, realmente crea un recurso de sesión. Y con cierre de sesión, elimine, elimine el recurso. Es mucho mejor se explica en el rieles tutorial libro que recomiendo: http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec:sessions

Para recapitular, esto le puede ayudar a averiguar cuando necesite nuevo controlador:

• Cuando se piensa en poner no REST acciones en el controlador como log_in, calculate_date, ect.
• Cuando hay algo que puede nombrar y que es "interesante" lo suficiente como para ser un recurso separado.
• Además, cuando se está desarrollando en el "afuera hacia adentro" estilo, tales respuestas son más naturales: http://rubylearning.com/blog/2010/10/05/outside-in-development/

En general, el aprendizaje sobre el descanso y su filosofía va a ayudar mucho.

Answer 2

Un controlador se puede usar para crear páginas sin límite para un modelo. Un ejemplo de eso podría ser un aviso legal o algo así. como eso. Cosas estáticas, ...

A Controller controla los datos. En la mayoría de los casos, estos datos provienen del Model, pero esto no es necesario ya que es la combinación más común.

Answer 3

Obviamente, no hay una regla rígida; pero yo creo que es útil pensar en términos de lo que los tres diferentes partes del MVC representan (o "hacer"):

• Modelos representan los datos y back-end-lógica de los datos
• controladores dejar que el usuario interactuar con los modelos
• Vistas son lo que el usuario ve cuando el usuario interactúa a través de un controlador

cont Tan diferente Se usarán rodillos para cuando desee hacer diferentes (categorías de) cosas.

Por ejemplo, en el libro AWD, la aplicación Depot funciona (ampliamente) manipulando y almacenando Productos, por lo que tiene un modelo de Producto.

Hay dos formas distintas de interactuar; como propietario del Depósito (agregando productos, ajustando precios y existencias ...) o como cliente (agregando productos a su carrito, pagando ...). Por lo tanto, tiene un controlador de administración para el primero y un controlador de tienda para este último.

Otra razón, y una que a menudo se vinculará con la primera, es si sus controladores necesitan una envoltura diferente. Por ejemplo, necesita autenticar al usuario antes de hacer cualquier cosa de Adminy, pero no para cosas basadas en el Cliente. De modo que puede separar las acciones en dos controladores y poner un before_filter en el administrador para manejar la autenticación.

Answer 4

También soy nuevo en RoR y estoy haciendo un tutorial de Michael Hartl. Encontré en mi investigación y en hablar con un Rubyista experimentado que cuando necesitas la ayuda de tu Modelo (base de datos) debes crear un Controlador. Por ejemplo, si está creando una sesión y el método que está creando va a necesitar una interfaz con el Modelo (base de datos) al usar, almacenar, actualizar, agregar (comportamiento RESTful), entonces necesitará un controlador.

¿Por qué? Como se dijo antes: el trabajo de marco MVC requiere que los controladores sean el único elemento que puede interactuar con los modelos (¡como un gorila en la sección VIP de un club nocturno lleno de mujeres calientes! ¡Los geeks están representados por "la vista" LOL! !) !!