1. Inicio
  2. Pregunta y respuesta
  3. Hierarchic MVC en Rails 3?

Hierarchic MVC en Rails 3?

2010-08-25 19 views

Respuesta

3

Según los comentarios a la respuesta de Toby, parece que le gustaría poder usar aplicaciones MVC como componente en una nueva aplicación. Rails Engines (Ver http://rails-engines.org) proporciona esta funcionalidad. Simplemente instala la gema de los motores y coloca las aplicaciones en proveedores/complementos y se puede acceder a sus modles/vistas/controlador.

Esto realmente no se ajusta a HMVC donde los controladores en la nueva aplicación delegan a otros controladores. Pero como Toby, no veo la ventaja de eso.

Cuál es agradable sobre el enfoque de los motores es que más puede montar cualquiera de los modelos en el plugin con sólo añadir una versión del modelo a la nueva carpeta de aplicaciones app/modelo (lo mismo se aplica para las vistas y controladores)

Tengo aplicaciones/vistas/diseños superpuestos para dar a mi aplicación/complemento de autenticación la misma apariencia que la aplicación en la que está incluido.

Para Rails 3 Railtie toma el lugar de los motores y es compatible oficialmente (y realmente utilizado - Action Mailer es un plugin de Railtie. Todavía no lo he usado.

Chec k usted mismo en http://edgeapi.rubyonrails.org/classes/Rails/Railtie.html

Una buena escritura en él está también aquí http://www.igvita.com/2010/08/04/rails-3-internals-railtie-creating-plugins/

Fuente

2010-09-09 14:58:29 Will

+0

¿Cuáles son las diferencias/ventajas del uso de los plugins de Railties sobre Rails? –

+0

Puede encontrar una justificación para Railtie aquí http://www.engineyard.com/blog/2010/rails-and-merb-merge-rails-core-part-4-of-6/ – Will

+0

Desde el sitio de Railtie "Developing una extensión Rails no requiere ninguna implementación de Railtie, pero si necesita interactuar con el framework Rails durante o después del arranque, entonces Railtie es lo que necesita para hacer esa interacción ". – Will

2

Rails ha tenido complementos durante mucho tiempo.

Dudo que exista una razón técnica por la cual un controlador no podría despachar a otro controlador, pasando el objeto de solicitud a lo largo de una cadena. Simplemente no sé lo que gana al hacerlo, el diagrama parece espagueti.

Para mí es un uso indebido de MVC. Sugeriría que es mucho más simple y más fácil de implementar la lógica en modelos y clases de nivel inferior y crear un único controlador que enfrente esta lógica, en lugar de crear una cadena de controladores.

Fuente

2010-08-25 22:15:36

+0

No me acuerdo aquí. Tal vez estoy agregando algunas características nuevas que podrían ser independientes ... entonces es bueno tenerlo como un componente MVC independiente en lugar de incorporar todo en la aplicación principal MVC, por lo que es reutilizable para otros proyectos. Además, todos los componentes de MVC que ve en el diagrama podrían ser de un proveedor de terceros. No los mezclaría dentro de mi aplicación principal MVC.El diagrama no me parece espagueti, parece estar muy bien estructurado. Delegue en lugar de tirar todo en una gran parte que se hará cada vez más grande. –

+0

Creo que es una abstracción con goteras. ¿Qué ventajas trae que una capa de objetos bien estructurada que maneje su lógica de negocios no pueda alcanzarse de una manera más granular y fácil de probar? –

+0

Y votar por mí porque tengo serias y bien pensadas reservas sobre el estilo arquitectónico es un poco duro. –

1

En la publicación de blog de Rails 3, DHH mencionó el proyecto the Cells. No lo he usado, pero lo voy a verificar.

El ejemplo de carrito muestra bien cómo ese tipo de funcionalidad podría limpiar el código de la aplicación. El código que recupera datos debe colocarse en algún lugar del controlador. En cada acción o en un filtro anterior. La celda parece ser una solución mucho mejor.

Fuente

2010-09-08 06:57:46

Cuestiones relacionadas

 Cuestiones relacionadas