¿Por qué MODEL en ASP.NET MVC a veces se usa como parte de una aplicación que habla con una base de datos como here y a veces como un objeto comercial que "recorre" aplicaciones entregando datos como here?Significado del modelo en MVC
MVC ha evolucionado en diferentes direcciones desde sus comienzos en Smalltalk hasta el punto en que a menudo se usa para describir arquitecturas muy dispares, como habrás descubierto.
Martin Fowler bloguea sobre la evolución de MVC aquí. http://martinfowler.com/eaaDev/uiArchs.html
Hay una explicación de las diferencias entre MVC, MVP y MVVM aquí: http://joel.inpointform.net/software-development/mvvm-vs-mvp-vs-mvc-the-differences-explained/
Mi 10c:
Hay muchos ejemplos de ASP.NET MVC 3 están más estrechamente alineados con el patrón MVVM de MVC. En MVVM, ViewModels está diseñado para los datos específicos de cada vista (es decir, 'ViewModels' no son simplemente modelos de dominio, sino que están decorados con aspectos de vista/nivel de presentación como reglas de validación, indicaciones de campo/nombres, visibilidad de campo, etc.).
(Volver a MVC) En los datos más pequeñas centradas en proyectos sin mucha necesidad de organización en niveles back-end, M puede ser tan simple como un modelo ORM (por ejemplo, un .edmx con un poco de POCOs autogenerado) con unas pocas reglas. En este caso, MVC podría considerarse una arquitectura de aplicaciones.
Pero en proyectos más grandes que usan MVC, el original (Smalltalk) 'M' del modelo ahora se divide en varias otras capas, p. entidades de dominio, fachadas de servicio, servicio (por ejemplo, SOA), negocio y niveles de datos, etc. (así que aquí, M VC es un patrón de nivel de presentación, y M es el resto de su sistema). Entonces, por ejemplo, en un proyecto de este tipo, la carpeta 'Modelos' de su proyecto MVC podría ser referencias de servicio proxy y entidades de dominio proxy utilizadas para comunicarse con el 'back-end' de su sistema, o incluso una abstracción de esta comunicación (por ejemplo, ver las fachadas de servicio/agente de servicio utilizadas en el Bloque de aplicaciones compuestas).
La primera imagen indica que un controlador crea un modelo de la base de datos y luego pasa el modelo a la vista. El segundo es el mismo pero contiene solo una vista simple.
Es posible que desee comprobar:
DTO Pattern + Lazy Loading + Entity Framework + ASP.Net MVC + Auto Mapper
pienso en ella como la "lógica de negocio" o "las cosas a los usuarios obtener desde el sitio, no cómo se ve" .
Porque ambas cosas son parte de lo que se supone que el componente 'Modelo' en MVC debe hacer.
En términos generales, los papeles de los tres componentes son:
A diferencia de la arquitectura Multi-Tier, MVC no distingue entre lógica de dominio y persistencia de datos: el Modelo implementa ambos.
En realidad, sin embargo, la mayoría de las implementaciones de MVC no son 100% correctas. Es bastante común ver el Modelo reducido a una capa de acceso a datos, con gran parte de la lógica de dominio ocurriendo en el Controlador. De hecho, a veces no está claro dónde termina la validación de entrada (el trabajo del Controlador) y comienza el procesamiento real del dominio (el trabajo del Modelo). También existe cierta controversia sobre cómo los datos fluyen del Modelo a la Vista: ¿el Controlador vuelve a leer los datos del Modelo y los pasa a la Vista, o el Modelo pasa activamente sus resultados a la Vista? ¿O debería la Vista ser la parte activa, consultar el Modelo de datos?
En el patrón de controlador de vista de modelo, el controlador es líder. Determina qué vista se representa y los datos pasan a esa vista.
La mayoría de las veces estamos acostumbrados a una arquitectura que utiliza una base de datos para conservar el modelo. Pero eso no es un requisito. El modelo también puede persistir en otra cosa (XML o servicios web, por ejemplo).
La M también podría representar un modelo de vista. Eso significa que no está pasando el modelo real de la base de datos al controlador para ver, sino que está utilizando un modelo que está específicamente diseñado para la vista.
Cuando se usa el Diseño Dirigido por Dominio, su controlador solo actúa para invocar funciones en su dominio. El modelo de dominio contiene la lógica comercial real y expone los servicios para acceder a su tienda de persistencia (repositorios) y para crear nuevos objetos (fábricas). El controlador debería ser lo más plano posible.
Los modelos son la parte más confusa de MVC para comprender.
Algunas personas piensan en términos de modelo de negocio, por lo que hacen cosas como tener su modelo de hablar directamente a una base de datos.
Otros piensan en términos de modelos de vista, por lo que terminan con clases de datos más simples.
Personalmente, estoy con el segundo grupo, ya que creo que ofrece una mejor separación de las preocupaciones.
Si alguien puede encontrar los artículos originales, ¿podrían incrustar las imágenes? Parece que no puedo acceder a ninguno de ellos. –