Diferencia entre la arquitectura de 3 niveles y MVC (modelo, controlador de vista) en ASP.Net

Me encantaría saber cómo la arquitectura de 3 niveles difiere de MVC (Modelo, Controlador de vista) en ASP.Net, ya que me parece que se aplica la misma arquitectura.

En 3 niveles que tenemos User Services Layer, BusinessLayery DataAccessLayer, por otro lado tenemos Model, Viewy Controller. Esto me parece la misma arquitectura.

¿Alguien puede explicar si lo que realmente difiere de las dos arquitecturas, cómo cada capa difiere entre sí?

Esto es como preguntar cuál es la diferencia entre una manzana y un núcleo de manzana. Estas dos arquitecturas no son reemplazos entre sí. Creo que una vista más precisa es que la arquitectura de 3 niveles aumenta MVC.

La arquitectura MVC

• Modelos: representan "cosas" en su aplicación. Esta capa se ha vuelto un poco borrosa en los últimos años, como explicaré más adelante.

• Vistas: la interfaz de usuario. La cosa con la que el usuario interactúa.

• Controladores: el código de programación que responde al usuario y a los cambios en la capa del modelo

La arquitectura de 3 niveles

Con la arquitectura de 3 niveles, tiene capas con diferentes responsabilidades.

• Servicios de usuario: (o "servicios" en general) Esta capa tiene más que ver con la coordinación de la recuperación y las modificaciones de la capa "modelo". Aquí se realizan acciones complejas de varios pasos.

• Capa empresarial: representa las reglas comerciales grabadas en el código de programación. Lo que quiere "The Business" se aplica en esta capa.

• Capa de acceso a datos: una o más clases responsables de acceder a un almacén de datos persistente.

La única parte de la arquitectura de 3 niveles que se cruza con MVC es la "capa empresarial". Los "Modelos" en MVC y la "Capa empresarial" en la arquitectura de 3 niveles están tratando de lograr el mismo objetivo.

La "M" en MVC se ha vuelto borrosa

La capa "modelo" en MVC se ha expandido en los últimos años. Por lo que he visto, hay dos, posiblemente tres tipos de modelos:

1. Modelos de dominio: estos representan las "cosas" que le importan a "The Business": el dominio empresarial. Estas clases contienen datos y todos los procedimientos que operan en esos datos para hacer cumplir las reglas comerciales. Con frecuencia, los modelos de dominio están vinculados a tablas en una base de datos. Esto parece ajustarse a la "capa empresarial" de la arquitectura de 3 niveles.

2. Modelos de vista: Estas son clases utilizadas para dar masajes a los datos de los modelos de dominio en algo más agradable a la vista. Esto no cabe en ninguna parte de la arquitectura de 3 niveles porque los modelos de vista no implementan la lógica empresarial, ni proporcionan ningún tipo de servicio o acceso a datos.

3. Modelos de negocios: en aplicaciones complejas, surge la necesidad de desacoplar el modelo de dominio de la lógica de negocios. Los Modelos de Negocio contienen datos y procedimientos que operan en esos datos para implementar reglas de negocios, y los Modelos de Dominio son relegados a "Bolsas de Propiedades" - objetos que solo contienen datos pero no contienen comportamiento. Los modelos de dominio se convierten en otra forma de objeto de transferencia de datos entre la base de datos y la aplicación.

En ninguna parte de MVC se menciona el acceso a datos. En algunos casos, verá que el acceso a datos pertenece a la capa "modelo" de MVC, que como hemos visto ya no es una capa clara. Realmente veo que la arquitectura de 3 niveles se combina con MVC para crear una aplicación completa. Uno aumenta o mejora sobre el otro:

• Modelos
  • Modelos de dominio (MVC / 3 niveles)
  • Ver modelos (MVC)
  • (opcionalmente) Modelos de negocio (MVC / 3 niveles)
• Vistas (MVC)
• Controladores (MVC)
• Acceso a datos (3 niveles)
• Servicios (3 niveles)

Hay alguna intersección, pero están en gran parte separadas, y juntas se usan para desacoplar y aislar varios componentes de un sistema más grande.

No, no son lo mismo.

MVC es un patrón de diseño para estructurar el código de la interfaz de usuario. Podría usarse en una arquitectura de tres niveles, en cuyo caso el patrón pertenecería a la capa de servicios del usuario. Pero también se puede usar para la interfaz de usuario en aplicaciones que no son de tres niveles, por ejemplo, una calculadora sin persistencia subyacente y, por lo tanto, sin capa de acceso a datos.

En una arquitectura de tres niveles con una interfaz MVC, los objetos de dominio utilizados como modelo serían los objetos de la capa empresarial, pero el patrón MVC realmente no especifica qué tipo de objetos es el modelo, solo cuál es su papel en el patrón es. Por ejemplo, en la variante MVVM, los modelos son adaptadores específicos de UI en la parte superior de los objetos de dominio. En este caso, incluso el modelo pertenece a la capa de servicio del usuario.

Sé que habrá toneladas de respuestas diferentes, pero les daré mi opinión sobre esto.

Es la respuesta más famosa en ingeniería de software "Depende".

Esencialmente si lo miras, además de varias implementaciones y diferencias teóricas, estos son patrones muy similares con flujos similares.

Donde depende depende de la aplicación que está creando, una aplicación web simple puede tener solo una capa MVC que habla a través de un ORM a la base de datos. Una más compleja puede tener MVC manejando el front-end en la capa de usuario, con operaciones expuestas no complejas más complejas que ocurren en la capa BL, con la capa de datos que consta de múltiples fuentes.