asp.net mvc - ventajas - ¿A qué tipo de arquitectura se llama esto?

mvc ejemplos (4)

Como tiene un DAL separado del modelo de dominio y también tiene la capa de servicio, parece que se dirige a DDD (diseño impulsado por el dominio). Aquí hay una discusión sobre este enfoque que puede ser útil saber.

Para la aplicación web (ASP.NET MVC) que estoy desarrollando actualmente, tenemos la siguiente arquitectura en su lugar:

Data Access Layer : lógica para la persistencia de datos en una base de datos arbitraria
Domain : el modelo de datos
Service Layer : lógica empresarial (por ejemplo, procesamiento de pedidos, gestión de cuentas, etc.)
Controller : consume servicios y proporciona / recibe datos a / desde la Vista
View : la interfaz de usuario para el usuario

En esencia, tomé el Model y lo dividí en DAL , Service Layer y Domain . Sentí que rellenar toda la lógica dentro del Model hizo que mi código fuera demasiado complicado. Además, sentí que me dejaba expresar mi lógica empresarial limpiamente sin hacer que el controlador hiciera demasiado trabajo.

Mi pregunta es: ¿cómo se llama este tipo de arquitectura?

Como una pregunta secundaria : ¿este tipo de arquitectura tiene sentido? Si no, ¿estoy haciendo algo mal?

Desde un alto nivel, lo describiría como una arquitectura en capas. Describirlo como un diseño impulsado por dominio también miraría patrones más pequeños como el agregado, el repositorio, los contextos delimitados, etc. No puedo decir solo por su descripción.

Si la capa de dominio reside en un conjunto / paquete que no hace referencia a ninguno de los demás, entonces tiene el núcleo de los principios de Onion Architecture , que son:

La aplicación se basa en un modelo de objetos independiente
Las capas internas definen interfaces. Las capas externas implementan interfaces
La dirección del acoplamiento está hacia el centro
Todo el código central de la aplicación se puede compilar y ejecutar por separado de la infraestructura

Una cosa concreta a buscar es si su DataAccess hace referencia al dominio.

Está en el camino correcto sobre DDD, dependiendo de cuán delgadas / gruesas sean las capas de dominio y servicio. DDD dice que el conocimiento (es decir, la lógica de negocios) debe crujirse en el modelo de dominio. Mover las preocupaciones de acceso a datos a DAL está en línea con DDD, pero creo que mover la lógica de negocios a una capa de servicios no lo es. Si tiene una capa delgada de "Modelo de datos" de dominio (principalmente para entidades) y una capa de Servicios gruesa (sobre todo para "lógica comercial"), es posible que tenga un dominio anémico .

Además, técnicamente no hay "Capa de servicio" en DDD. Puede haber una "capa de aplicación", pero debe ser delgada, y solo responsable del flujo de aplicaciones / administración de las duraciones de la clase de dominio. Esto es esencialmente lo que hacen los Controladores en .NET MVC, administra el flujo de aplicaciones en el contexto de la http de la web.

Si rellenar toda la lógica dentro del Modelo hizo su código demasiado complicado, me interesaría escuchar ejemplos de lo que quiere decir con "demasiado complicado". Podrías modelar correctamente un dominio complejo, o hay posibilidades de que hayas recurrido a los patrones DDD para simplificar las cosas. Diría que como lo mencionaste en tu pregunta, el arco no es DDD. Simplemente lo llamaría "arquitectura en capas", pero eso es porque prefiero usar el término "nivel" solo cuando se habla de arco físico. Sin embargo, su arquitectura lógica está en capas.

Me gusta mucho que Darin vincule al arco de cebolla en su respuesta. Me estoy convirtiendo en un gran admirador de esto, y me parece que no es exclusivo de DDD en absoluto. Si su código usa inyección de dependencia para resolver dependencias de interfaz con implementaciones en tiempo de ejecución, puede tener una forma de arco de cebolla. Por ejemplo, ¿define alguna interfaz en su DAL? ¿Las implementaciones de esas interfaces se resuelven en tiempo de ejecución?

Aquí hay un ejemplo de un arco que estoy comenzando a usar en mis nuevos proyectos. Es una combinación de cebolla + DDD:

Proyecto / ensamblado API : interfaces genéricas, enumeraciones, clases y métodos de extensión utilizados por todas las demás capas. No necesita estar separado del dominio, pero puede.
Proyecto / Asamblea de Domain : todas las entidades y lógica de negocios. Depende solo de API . Utiliza patrones DDD como fábrica, servicio, especificación, repositorio, etc. También contiene más interfaces específicas de dominio que no están definidas en la API.
Proyecto / Montaje Impl : implementaciones de interfaces definidas en API y Domain . Aquí es donde se implementa el EF DbContext, así como cosas como el registro, el envío de correo electrónico, etc. Todas estas implementaciones son de inyección de dependencia, por lo que técnicamente podría tener varios proyectos / ensambles Impl.
Proyecto / Asamblea UI : este es el proyecto MVC. Los controladores consumen la superficie del dominio directamente y no pasan por una aplicación o capa de servicio. Cualquier dependencia de interfaz en fábricas, servicios, repositorios, etc., se inyecta en el dominio por el controlador utilizando MVC IoC (inyección de constructor).

Coloqué una capa de API en el núcleo mismo, pero podría combinar los proyectos de API y Dominio en uno solo. De cualquier manera, la gran parte carnosa de la cebolla es el Dominio, y tiene estratificación interna. Por ejemplo, los Servicios pueden depender de Fábricas, que dependen de Repositorios, que dependen de Entidades.

El proyecto Impl es lo que ves como la piel de cebolla "Infraestructura" en el diagrama de Palermo. Está en el borde exterior junto con la IU, y no contiene ningún conocimiento específico del dominio. Sabe cómo enviar correos electrónicos, almacenar / recuperar datos usando EF, etc. Si lo desea, puede tener más de uno de estos, por ejemplo, 1 Impl para acceso a datos, 1 Impl para tratar con correo, etc.

MVC tiene los Controladores y Vistas, y se concentra en la UI y el flujo de aplicaciones web. Cualquier cosa que requiera conocimientos específicos del dominio se delega en el dominio, y las clases de dominio se inyectan en el controlador. Esto significa que cualquier interfaz inyectada por el constructor en clases de dominio se resuelve automáticamente por el contenedor IoC.

Como nota final, la programación contra las interfaces definidas en las clases API y Dominio significa que puede probar el proyecto de dominio por separado del proyecto MVC.

Puede haber diferentes nombres dependiendo del ángulo en que lo mires. Entonces todavía es MVC, es solo que tu M está dividida en varias capas. También podría llamarse arquitectura Multitier (o arquitectura N-tier). Jeffrey Palermo también utilizó la noción de arquitectura de cebolla .