¿Dónde entra la lógica comercial en los rieles?

Question

Soy un desarrollador de ASP.NET MVC que acaba de comenzar con mi primer gran proyecto sobre raíles. Sin embargo, estoy confundido acerca de dónde ubicar su lógica comercial. en ASP.NET creo una biblioteca que contiene servicios (diseño impulsado por Dominio) que maneja la lógica de negocios, he escuchado que rails usa un concepto de controlador skinny modelo flaco pero tengo algunos proyectos en ASP.NET que agregan toda la lógica al controlador crearía un gran lío, ¿hay alguna otra manera?

Answer 1

Vaya con el concepto de FatModels y SkinnyControllers. Sus modelos deben saber cómo se comportan y qué deben hacer.

Cuando sus modelos estén demasiado gordos, extráigalos en módulos reutilizables e inclúyalos en su módulo.

• Example of taking a fat controller (with logic) and moving to a model
• Example of taking code from the views and moving into the model

Usted puede probar fácilmente el comportamiento de los modelos que utilizan RSpec (o test/unit o la debería). Luego puede probar que la aplicación se comporta correctamente con Cucumber.

Answer 2

Puede poner la lógica de negocios en cualquier lugar que desee (incluso en las vistas, aunque esa es una mala idea).

Yo diría que si la lógica está vinculada a un objeto del mundo real, entonces póngalo en el modelo. De lo contrario, use el controlador. Pero depende de usted determinar cómo hacerlo para su aplicación. Los modelos son para modelar cosas, y los Controladores son para controlar cosas.

Answer 3

"Business Logic" o algunos podrían llamarlo "Domain Logic" no pertenece a ningún lugar cerca de Rails y/o su proyecto .NET MVC. Rails y MVC deberían depender de su Dominio, no al revés. Recomendaría leer sobre la arquitectura de cebolla de Jeffery Palermo o ver "Arquitectura de los años perdidos" de Robert Martin. (Creo que esa es la charla de todos modos). Probablemente haya más recursos que eso, pero te agradecerás más adelante por tratar tanto a Rails como a .NET MVC como los frameworks de terceros que son, y no como la casa principal de tu aplicación.

Answer 4

creo que este artículo de blog proporciona una buena visión general de una estrategia de incorporar el diseño de dominio impulsada con en el marco rieles: http://www.smashingboxes.com/domain-logic-in-rails/

TL; DR

Refactor sus modelos carriles clásicos en los repositorios, y utilizar una capa de fachada en los controladores para interactuar con su modelo de dominio.

Estoy luchando con esto un poco yo mismo, y por mucho que el patrón de controlador de grasa parece prevalecer, cualquier cosa "grasa" en el software parece ser un olor, violando la responsabilidad individual.