¿Dónde están las reglas comerciales en MVC?

Question

Ahora que todos hablan de MVC, me doy cuenta de que no se están abordando las reglas comerciales. En los viejos tiempos de la arquitectura de 3 niveles, las reglas de negocios estaban en la capa intermedia. ¿Dónde caen en el nuevo MVC?

Answer 1

Al primer pincel, diría que pertenecen al modelo. La Entrada MVC en Wikipedia parece estar de acuerdo: " En MVC, el modelo representa la información (los datos) de la aplicación y las reglas comerciales utilizadas para manipular los datos " ;. Después de todo, por "Reglas de negocios" nos referimos a los algoritmos funcionales y la lógica que codifican el dominio en el que está involucrada su aplicación, a diferencia de la lógica relacionada con la entrada / salida. Esta lógica central relacionada con el negocio no cambia o no debe cambiar según lo que se muestra al usuario (que es el dominio de la Vista) o la entrada del usuario (que es principalmente recibida por el Controlador).

En mi experiencia, hacer este tipo de pregunta ha sido muy revelador durante el proceso de desarrollo del software: encontramos un gran número de cosas que algunas personas consideraban "reglas de negocios", pero resultaron ser otra cosa. Si no es una verdadera regla de negocios, es posible que no pertenezca al modelo.

Answer 2

La razón por la que nunca ve la dirección de MVC " Reglas comerciales " es que MVC en general es un patrón de presentación. Está enfocado en cómo estructurar su aplicación. El Modelo, por ejemplo, puede considerarse como un modelo de presentación. El modelo de su aplicación, que luego la vista representa.

Sin embargo, para crear el modelo de presentación, generalmente necesita ir a sus modelos de dominio donde reside toda su lógica de negocios. En ese momento, MVC no dicta dónde vive ese código físicamente. ¿Está en otro nivel? MVC no le importa.

Answer 3

Las reglas de negocio siempre viven en el modelo. El modelo es el bit que podría reutilizar con una IU completamente diferente. La vista obviamente depende completamente de las opciones de IU y el controlador tiene que tomar datos del modelo y decirle a la vista que lo represente.

Poner la lógica de negocios en la vista es malo porque vincula la estructura con la presentación.

Poner la lógica de negocios en el controlador es malo porque divide su dominio de negocios entre los datos persistentes por el modelo y las reglas en el controlador.

Answer 4

Una cita de una Wikipedia Artículo :

MVC se ve a menudo en aplicaciones web, donde la vista es la página HTML real, y el controlador es el código que recopila datos dinámicos y genera el contenido dentro del HTML. Finalmente, el modelo está representado por el contenido real, generalmente almacenado en una base de datos o en nodos XML, y las reglas comerciales que transforman ese contenido en función de las acciones del usuario.

Answer 5

¿Hay alguna razón por la que no puedes mezclar MVC y Ntier? Nuestra aplicación hace exactamente eso. Nuestros controladores se utilizan para la validación de datos y deciden qué llamadas de Business Layer realizar.

OurApp.Web - Proyecto MVC Asp.net
OurApp.Business - Biblioteca de capa empresarial
OurApp.DataAccess - Biblioteca de capa de datos
OurApp.Entities - Básicamente todos los 'modelos' compartidos por todas las capas

Answer 6

Las reglas de negocios deben estar en el modelo, NO en el controlador. El controlador y la vista son parte de la capa de presentación.

El modelo representa las entidades y la funcionalidad del dominio.

El controlador es simplemente un administrador para tomar las entradas y solicitudes del usuario, realizar acciones en / en el modelo y asignarlo a vistas en la capa de presentación. El controlador tampoco es solo un mediador, la vista O el controlador puede actuar sobre el modelo.

Answer 7

Esta es una pregunta publicada anteriormente, pero me gusta que el repositorio de reglas sea completamente independiente de cualquier parte de una aplicación. Las aplicaciones múltiples, las implementaciones múltiples de un nivel empresarial, deberían poder acceder a una representación estática de un repositorio de reglas empresariales. Las decisiones de separación simples como esta hacen una migración desde el escritorio - > web, por ejemplo, trivial.

En mi arquitectura, Ver - > Modelo - > Controlador - > Nivel empresarial - > El repositorio de reglas, es decir, el controlador accede a datos gruesos tal como los presenta el nivel / capa empresarial, los alimenta al modelo que los masajea en una forma presentable, y la vista los muestra pasivamente. El nivel empresarial, que se puede reutilizar en cualquier formato de presentación, tendrá reglas explícitas y acceso a un subsistema con reglas implícitas. Por diseño, cada componente ignora los detalles de un componente por encima de él.

Answer 8

Creo que el problema es una cuestión de definición. Me parece que la lógica para presentar las pantallas en el orden necesario es un problema del controlador y he visto algunos proyectos que utilizan un motor de reglas para determinar el orden y qué es lo que se requiere información del usuario. Esto no es lo mismo que las reglas de negocio en mi humilde opinión.

Answer 9

Ustedes están equivocados, las reglas de negocio viven dentro del controlador y no del modelo ...