Ahora que todo el mundo está hablando de MVC, noto 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?Dónde están las Reglas de negocios en MVC
En el primer cepillo, diría que pertenecen al modelo. El MVC Entry on Wikipedia parece estar de acuerdo: "En MVC, el modelo representa la información (los datos) de la aplicación y las reglas de negocio utilizadas para manipular los datos". Después de todo, por 'reglas empresariales' nos referimos a los algoritmos funcionales y la lógica que codifica el dominio con el que está involucrada su aplicación, a diferencia de la lógica relacionada con entrada/salida. Esta lógica central relacionada con el negocio no cambia, o no debería, según lo que se muestra al usuario (que es el dominio de la Vista) o la entrada del usuario (que es recibida principalmente por el Controlador).
En mi experiencia, hacer este tipo de preguntas ha sido muy revelador durante el proceso de desarrollo de software: encontramos una gran cantidad de cosas que algunas personas consideraban 'reglas de negocios', pero que resultaron ser otra cosa. Si no es una regla comercial verdadera, es posible que no pertenezca al modelo.
Sin embargo, el modelo NO debería estar en el proyecto MVC y no debería tener dependencias en ninguna tecnología de IU particular. – Andy
Una cita de una Wikipedia Article:
MVC se ve a menudo en aplicaciones web, donde la vista es la página real de HTML, y el controlador es el código que recoge 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.
Eso no es MVC. MVC se trata de organizar el código. Todas las páginas web dinámicas serían MVC según su definición. –
¿Hay alguna razón por la que no pueda mezclar MVC y Ntier? Nuestra aplicación hace precisamente eso. Nuestros controladores se utilizan para la validación de datos y deciden a qué Business Layer llama.
OurApp.Web - Proyecto Asp.net MVC
OurApp.Business - Negocios Capa Biblioteca
OurApp.DataAccess - Capa de datos de la biblioteca
OurApp.Entities - básicamente todos los 'modelos' compartido por todas las capas
Me gusta este enfoque. Lamentablemente, creo que muchos frameworks web hacen que este salto sea incómodo. En algún momento puede necesitar objetos auxiliares en la capa de su empresa que no correspondan necesariamente con ninguna tabla de base de datos/almacenamiento persistente, algo que todas las clases de modelos que he visto parecen creer que es una cuestión fundamental. En ese punto te preguntas, ¿dónde coloco este código? – Koobz
Las reglas comerciales siempre viven en el modelo. El modelo es el bit que podrías reutilizar con una interfaz de usuario completamente diferente. La vista es obviamente completamente dependiente de las opciones de IU y el controlador debe tomar datos del modelo y decirle a la vista que lo renderice.
Poner lógica de negocios en la vista es malo porque vincula la estructura a la presentación.
Poner lógica empresarial en el controlador es malo porque divide el dominio de su empresa entre los datos que persisten en el modelo y las reglas en el controlador.
La razón por la que nunca ves la dirección MVC "Reglas de negocio" 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 la vista luego representa.
Sin embargo, para crear el modelo de presentación, generalmente necesita ir a los modelos de su dominio donde vive toda su lógica comercial. En ese momento, MVC no dictamina dónde vive ese código físicamente. ¿Está en otro nivel? MVC no le importa.
Esta debería ser la respuesta –
Ustedes están equivocados, las reglas de negocio viven dentro del controlador y no del modelo ...
aceptada cualquier argumento allí? – Kamarey
Este comentario es simplemente INCORRECTO. El controlador es una parte técnica de la aplicación que orquesta los flujos de datos y desencadena acciones en el modelo y la vista. En una aplicación de PC típica, el controlador se preocupa por los eventos del mouse, las pulsaciones de teclas y cosas similares. –
Las reglas comerciales 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 entidades y la funcionalidad del dominio ..
El controlador es simplemente un gerente para la toma de entrada del usuario y solicitudes, la realización de acciones en/sobre el modelo y mapeo que a puntos de vista en la capa de presentación. El controlador no es solo un mediador, la vista O el controlador puede actuar sobre el modelo.
Creo que mucha gente piensa implícitamente en el modelo como el "modelo de base de datos", por lo que las reglas de negocio no parecen tener un lugar. Si, por el contrario, ve el modelo como una simulación de algo del mundo real, entonces es obvio que las reglas comerciales son una parte tan importante del modelo como los datos que manipulan. –
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 de controlador y he visto algunos proyectos que usan un motor de reglas para determinar el orden y qué entrada es necesaria del usuario. Esto no es lo mismo que las reglas de negocios imho.
Creo que OP está hablando de lógica de negocios que pertenece al modelo. –
Esta es una pregunta publicada antiguamente, pero me gusta que un repositorio de reglas sea completamente independiente de cualquier parte de una aplicación. Varias aplicaciones, implementaciones múltiples de un nivel empresarial, deberían poder acceder a una representación estática de un repositorio de reglas de negocio. Las simples decisiones de separación como esta hacen que la migración del escritorio -> web, por ejemplo, sea trivial.
En mi arquitectura, Vista -> Modelo -> Controlador -> Business Tier -> Reglas Repositorio, es decir, el controlador accede a los datos gruesos presentados por el nivel/capa empresarial, los alimenta al modelo que los masaja en un presentable formulario, y la vista lo muestra pasivamente. El nivel de negocio, 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 sobre el mismo.
Entonces? Quicksort tiene 46 años y aún se usa. Lo importante es que funciona muy bien. –
Noté lo mismo hace unos años. Parecía que tan pronto como lo aprendí, comenzó a aparecer en todas partes que miré. –