Cómo se acomoda la arquitectura ASP.NET MVC en la arquitectura multicapa tradicional

Question

Pasando de la forma tradicional de diseñar aplicaciones web con una capa empresarial, capa de servicio, capa de acceso a datos y una capa de presentación al patrón de diseño MVC, me resulta difícil para entender cómo encaja en el viejo modelo.

Parece ser que el modelo MVC ya ha asignado la separación de las preocupaciones que se necesita y que se debe lograr mediante una arquitectura en capas. ¿Alguien puede arrojar algo de luz sobre este tema, por favor?

Como referencia, a continuación es como yo lo entiendo, por favor comparta su punto de vista sobre esta

Vistas MVC y controladores junto con Visualización de modelos -are- capa de presentación

Modelos de MVC - podía ser - capa de acceso a datos o de negocios o incluso capa capa de Servicio

Answer 1

veo la parte Asp.Net MVC sólo como la parte vista (o presentación) de toda la aplicación.

Luché también con el problema de cómo estructurar la aplicación de manera adecuada.
Tras la arquitectura de cebolla oí hablar de here (y sobre todo la imagen que se encuentra here), mi solución se ve de esta manera:

• Project.Core
  de lógica de negocios/servicios implementaciones, entidades, interfaces que deben ser implementadas por los otros proyectos (es decir, "IRepository", "IAuthenticationService", ...)
• Project.Data
  Conexión de base de datos: en mi caso, aquí se encuentran los repositorios de NHibernate y las asignaciones de entidades. Implementa datos -interfaces de Project.Core
• Project.UI.Web
  El Asp.Net MVC ("presentación") del proyecto - IT alambres toda la aplicación juntos.
  Tiene implementaciones para Interfaces en Project.Core y las conecta (y las de Project.Data) con algunos framework DI como Castle Windsor.

Project.UI.Web sigue las siguientes convenciones: (!)

• sus modelos son solamente ViewModels
• los vistas consumir su propio modelo de vista (uno view-one-viewmodel)
• controladores solo nee d para validar la entrada, transforma en objetos de dominio (como la lógica de negocio sabe nada acerca de exacly ViewModels) y delegado el trabajo real (lógica de negocio) para los servicios de oficina.

Resumen:
Si usted sigue este modelo es útil enfoque en Proyecto.Core: que es la aplicación real de . No se preocupa por la persistencia real de los datos ni se preocupa por cómo se presenta. Solo se trata de "cómo hacerlo". Pero está estableciendo las reglas y contratos (interfaces) para los que los otros proyectos deben proporcionar implementaciones.

Espero que esto lo ayude con la distribución de una aplicación Asp.Net MVC.

Lg
warappa

Answer 2

explicación muy básica:

Si crea una nueva aplicación MVC, obtendrá automáticamente una carpeta Controladores, Modelos y Vistas.

Sus actúan como controladores de la capa de negocios
modelos tienen acceso a datos/capa de Servicio
y las vistas son la capa de presentación.

Consulte http://www.asp.net/mvc para una explicación completamente detallada.

Answer 3

En resumen: nada cambia mucho.

Estoy familiarizado con algunos patrones de presentación: MVP (Modelo, Vista, Presentador, común en Windows forms/asp.net), MVC (Modelo, Vista, Controlador) y MVVM (Modelo, Vista, Modelo de visualización , comúnmente utilizado en WPF/Silverlight).

Enlace: http://haacked.com/archive/2008/06/16/everything-you-wanted-to-know-about-mvc-and-mvp-but.aspx

Por encima de enlace debe responder a algunos (si no todos) de sus preguntas. El modo en que generalmente escribo aplicaciones ASP.NET MVC es incluyendo al menos un híbrido de capa Service/Business para operaciones CRUD (¡porque el acceso a datos no pertenece ni al modelo de vista ni al controlador, y definitivamente no a la vista!).

Answer 4

Como han dicho otros, no cambia mucho. Mis aplicaciones son típicamente Architected como tal:

• modelo de capas (Modelos de Dominio y Ver)
• capa de repositorio (Data Access)
• capa de servicios (a veces implementada como servicios WCF en función de los app/requisitos)
• lado del servidor MVC capa (Asp.net sí MVC)
• MVVM lado del cliente o MVC (a través de ya sea Knockout.js, Backbone.js, o columna vertebral.js)

En la capa MVC del lado del servidor, mis métodos de controlador son muy livianos. Por lo general, llaman a un método en un objeto de capa de servicio para obtener algunos datos y transferirlos al cliente como datos de Json.

Porque estoy enviando a Json de vuelta, mis puntos de vista también son muy ligeros y escasos. Normalmente solo contiene secuencias de comandos y plantillas que se representarán con una biblioteca de plantillas del lado del cliente.