c# - net - MVC: ¿Dónde poner lógica de negocios?
routing in asp net mvc (9)
Antes que nada, he visto muchas preguntas sobre esto, pero no hay suficiente razonamiento detrás de eso. Si mi pregunta no es lo suficientemente buena y se debe eliminar, lo entenderé.
He echado un vistazo, por ejemplo, a this , y una respuesta de más de 45 votos confirma que aconseja poner la lógica comercial en el modelo, lo que suena bastante lógico.
Sin embargo, mi primer gran proyecto lo he hecho con todos mis BL completamente en los controladores, porque no cuestioné estas cosas y AccountController cómo se hace en AccountController que se agrega automáticamente si eliges MVC con autenticación de formularios. Todos los métodos lucen bastante rellenos con BL. O tal vez es la menor cantidad de código que se pudo agregar y estoy pasando por alto las cosas?
Una persona en youtube me preguntó si tenía razón al poner toda la lógica en sus modelos y ¡al principio yo no! Entonces comencé a pensar que tal vez él tenía razón?
Entonces, después de todo, ¿dónde pongo mi lógica comercial? Si está en las clases de modelos, entonces, ¿cuánto código debería considerarse una cantidad saludable en un método que está en el controlador? ¿Una línea para llamar a algún método del modelo en un controlador como máximo y luego regresar a la vista?
En términos generales, la lógica comercial no debe residir en ninguno de los reproductores MVC; solo debe ser consumido por las acciones de su controlador.
Como muchos han mencionado, es mejor crear una biblioteca para alojar la lógica de negocios como un conjunto de componentes reutilizables independientes del cliente.
Cuando se hace de esta manera, aumentamos enormemente la reutilización, la compatibilidad, la escalabilidad y la capacidad de prueba con nuestro software. También reducimos nuestra dependencia de ciertas características del marco, lo que hace que sea más fácil migrar a tecnologías más nuevas / diferentes.
Resumir nuestra lógica comercial en un ensamblaje independiente (o asambleas) nos ha servido bien a lo largo de los años. Nuestra lógica empresarial puede ser consumida por prácticamente cualquier tecnología .NET (ASP.NET MVC / API / Core, WPF, Win Forms, WCF, UWP, WF, consola, etc.).
Además, nos gusta que nuestro nivel intermedio maneje las reglas comerciales y la lógica de validación para reducir nuestras dependencias en .NET MVC Framework. Por ejemplo, evitamos el uso de los ayudantes de validación de .NET MVC y, en cambio, confiamos en el nuestro. Este es otro factor que nos permite consumir fácilmente nuestra lógica comercial desde cualquier tecnología .NET.
Lógicamente, el diseño de nuestro nivel medio de esta manera nos ha permitido lograr fácilmente esta arquitectura física:
Fue escrito con Peasy.NET , y nos ha servido bien a lo largo de los años. Tan bien que decidimos abrirlo.
Si alguien tiene curiosidad sobre cómo es nuestro nivel medio, aquí hay una sample de un cliente independiente, capa de negocios. También muestra el consumo de este por múltiples clientes .NET (ASP.NET MVC, Web Api y WPF).
¡Espero que esto ayude a alguien!
La lógica de negocios pertenece al dominio del problema y todo lo que pertenece al dominio del problema va al modelo en MVC.
El controlador debe ser responsable de pasar los datos del modelo a la vista y de la vista al modelo. Por lo tanto, el controlador es el puente entre lo que el usuario interactúa y cómo el programa modela y almacena el estado del problema. La fontanería , por así decirlo.
La clave aquí es la distinción entre la lógica comercial y la lógica de fontanería. En mi opinión, lo que hace el controlador de cuenta autogenerado es principalmente la fontanería, no la lógica comercial. Tenga en cuenta que la lógica de la instalación de fontanería no es necesariamente corta, por lo que no necesita imponer límites artificiales (como "X cantidad de llamadas como máximo en el controlador").
Me gusta mantener mis modelos limpios también (ref: @ Mark Walsh). El problema de no poder reutilizar la lógica integrada en los controladores puede superarse fácilmente a través de la inyección de dependencia, o, si cree que sería demasiado, exponga su lógica empresarial / de dominio a través de interfaces y use el patrón de fachada en los controladores. De esta forma obtendrá la funcionalidad que necesita, pero mantenga los controladores y el modelo limpios y agradables.
Me gusta mantener mis modelos limpios, es decir, solo con propiedades y sin lógica comercial. Siempre pienso que es bueno inyectar dependencias en el controlador y estas dependencias contienen la lógica que desempeño en mis modelos. Me gusta adherirme al principio de la responsabilidad individual siempre que sea posible y encuentro que los modelos con toneladas de métodos se inflaman rápidamente. Hay ventajas y desventajas para ambos, la inyección de muchas dependencias tiene una sobrecarga, pero permite probar de forma aislada y mantiene las clases simples y terminará teniendo controladores más delgados. A pesar de que mi lógica no existe realmente en mi modelo como miembros de la clase, su lógica de negocio sigue siendo. Tiendo a no tener la lógica de negocios definida en el controlador como cosas burlonas como el Httpcontext son un poco pesadillescas e innecesarias.
Mi equipo cuando se movió a mvc desde webforms (asp.net) hizo mucha investigación y se le ocurrió la siguiente estructura. Según yo, no se trata de cuán grande o pequeña es la aplicación. Se trata de mantener el código limpio y claro.
DALProject
AccountsDAL.cs --- > Calls SP or any ORM if ur using any
BLLProject
AccountsBLL.cs ---> Calls DAL
WebProject
Model
AccountsModel --- > Contains properties And call BLL
Controllers
IndexController ---> Calls Models and returns View
Views
Index
Los controladores deben ser responsables de los datos que pasan entre el modelo y la vista. Aparte de eso, no debería haber ningún código innecesario. Por ejemplo, si está registrando, debe hacerlo a nivel de modelo en lugar de controlador.
Parece haber cierta confusión sobre este tema. En general, parece que las personas tienden a confundir el patrón MVC con la arquitectura de N-niveles como una situación de uno o más. La realidad es que los dos enfoques se pueden usar juntos, pero uno no depende del otro y ninguno es necesario.
La arquitectura de N-tier se ocupa de separar una aplicación en varios niveles. Un ejemplo simple es cuando la aplicación se divide en una capa de presentación, una capa de lógica de negocios y una capa de acceso a datos.
MVC es un patrón de diseño relacionado con la capa de presentación de una aplicación. Es completamente posible diseñar una aplicación siguiendo un enfoque MVC sin separar la lógica de negocios y la lógica de acceso a datos de la capa de presentación y así terminar con un diseño de nivel único.
El resultado, si está siguiendo un enfoque MVC sin separar también la aplicación en niveles, es que termina con Modelos, Vistas y Controladores que tienen bits de reglas de negocio y lógica de acceso a datos mezclados con el resto de la lógica.
Por definición, en una arquitectura de N niveles, se supone que el nivel de presentación solo puede comunicarse con la capa de lógica de negocios, por lo que debe sostenerse que cualquiera de los componentes de MVC solo puede comunicarse con la capa de lógica de negocios.
Si está creando una aplicación que no involucra presentación, y por lo tanto no es una capa de presentación, no debería preocuparse por el patrón MVC. Sin embargo, muy bien puede dividir su aplicación en varios niveles y así seguir un diseño de N niveles aunque no haya una capa de presentación involucrada.
Prefiero poner lógica de dominio en el modelo por un par de razones.
El modelo no debe tener código de UI y, por lo tanto, será más fácil de probar. Siempre que sea posible, me gustaría tener un modelo completamente funcional (es decir, una cobertura de prueba completa) antes de escribir cualquier código de UI. El controlador puede confiar en que el modelo está haciendo lo correcto y solo se ocupa de las preocupaciones de UI.
Si pone la lógica de dominio en un controlador, no es tan fácil de compartir entre diferentes aplicaciones, o incluso entre diferentes controladores.
Sé que es una pregunta sobre MVC, pero creo que el ejemplo que estoy dando (Web API) será útil.
Estoy desarrollando mi primera API web y estoy reutilizando la lógica comercial de otras aplicaciones. Para ser específico, proviene de una DLL externa, por lo que mi API se usa solo para "hablar" con una solución SAP, recibir solicitudes de PO y devolver respuestas.
¿Cómo podría poner mi lógica (ya implementada) en mi controlador? No lo necesito Mi controlador solo recibirá, validará las solicitudes y redactará las respuestas para devolver los datos.
Estoy trabajando con las clases de ViewModel y todo lo que deben tener es una función de asignación, solo para leer información de TransferObjects (que proviene de la DLL externa) y traducirla a un ViewModel.
No me siento cómodo con mi aplicación (en este caso, API web) con la lógica de negocios, creo que la reutilización se perderá de esta manera.
Estoy tratando mi lógica comercial como una dependencia que inyecto en el controlador.
He hecho muchas refactorizaciones en el legado para proporcionar una solución de unidad comprobable, tuve que crear muchas interfaces e implementar algunos patrones de diseño en el legado para proporcionar esta solución.
Desde mi punto de vista, la capa de negocios debe estar separada de la aplicación, preferiblemente en otra biblioteca de clases. Entonces tendrá un concepto de separación real implementado en su aplicación.
Por supuesto, si su CORE (negocio) es su aplicación (API / WebSite) , las reglas de negocio se implementarán en sus clases de MVC. Pero en el futuro si quieres desarrollar una nueva aplicación y algunas reglas de negocio son las mismas, apuesto a que tendrás muchos problemas solo para mantener la misma lógica implementada en ambas aplicaciones.
También preferiría mantener los modelos limpios. Los controladores MVC deben usarse solo para hacer llamadas y también deben mantenerse limpios. De modo que, dependiendo de su reutilización, sensibilidad y relevancia, la lógica de negocios puede escribirse en
1. ControladorWebApi: la ventaja de utilizar un controlador webapi es que puede exponer estos servicios posteriormente a otros dispositivos, haciendo que su código sea reutilizable.
2. BAL / Common commonent: Hay algunas lógicas que tienen un uso específico y no se pueden exponer como api; se pueden empujar en esta clase.
3. Repositorio: todas las consultas relacionadas con la base de datos se agregan en un repositorio. Puede haber un repositorio genérico que implementará todas las funciones (operaciones CRUD) o repositorios específicos para cada tabla. Dependiendo de las operaciones que se realizarán.