Confundido con Model vs ViewModel

Question

Estoy aprendiendo ASP.NET MVC y descargué un par de aplicaciones de muestra. MusicStore, etc ...

Vengo de un fondo wpf donde teníamos el Patrón MVVM. Me di cuenta de que usaban el concepto de modelo y ViewModel.

En MVVM es bastante claro que vincula la vista al ViewModel que inyecta el modelo en viewModel. En MVC tiene un controlador, pero no estoy seguro y confuso cómo los une a todos, ya que no puedo ver el modelo se inyecta en el modelo de vista

que tienen la siguiente estructura

1. MyCompany.Entities.dll (Todos los modelos en este espacio) EG Producto
2. MyCompany.Dal.dll (Todos los repositorios en este espacio)
3. MyCompany.Services.dll (llamado por MyCompany.WebUI.Controller llama MyCompany.Dal)
4. MyCompany. WebUI.MyApp
5. MyCompany.Tests

De algunos de los ejemplos que he visto sus actos como un modelo ViewModel.Am en lo correcto?

Tomemos un controlador que tengo algo así como

public class ProductController 
{ 
    public ProductController(IProductRepository productRepository) 
    { 
     //omitted as not relevant 
    } 
} 
public class ProductVM 
{ 
    public ProductVM() 
    { 
     // Shouldn't we inject the model here RG Product 
    } 
} 

¿Hay algunos ejemplos de N-Capas por ahí que pueda referirse a? ¿El concepto de ViewModel es válido en MVC? ¿Cuál es el estándar?

Gracias por cualquier sugerencia.

Answer 1

Use ViewModels a simplifique the View.

Por ejemplo, puede tener un gráfico de objetos profundo con productos, pedidos, clientes, etc., y se requiere cierta información de cada uno de estos objetos en una vista particular.

Un ViewModel proporciona una manera de agregar la información requerida para una Vista en un solo objeto.

ViewModel también permite cosas como anotaciones de datos y validación, que no pertenecen a su modelo, ya que su modelo debe permanecer "específico del dominio".

Pero en realidad, ViewModels no es más que un simple contenedor para sus objetos de dominio.

Utilice una herramienta como AutoMapper para alternar entre sus modelos de vista y modelos de dominio con facilidad.

Personalmente i siempre se unen a ViewModel en mi vista, nunca a los modelos de dominio, incluso si es un solo objeto. ¿Por qué? Bueno, me gusta decorar mis ViewModels con UIHints, validación, anotaciones de datos. Del mismo modo que los modelos de dominio están enriquecidos con reglas específicas de dominio y lógica de negocios, sus modelos de vista deben enriquecerse con la lógica específica de la interfaz de usuario.

Si simplemente tiene un objeto con una representación de 1-1 de su modelo de dominio, le está faltando el punto de ViewModels.

Agregue al ViewModels solamente, y nada más, lo que se requiere para una vista en particular.

acción Ejemplo controlador

public ActionResult CustomerInfo(int customerId) 
{ 
    // Fetch the customer from the Repository. 
    var customer = _repository.FindById(customerId); 

    // Map domain to ViewModel. 
    var model = Mapper.Map<Customer,CustomerViewModel>(customer); 

    // Return strongly-typed view. 
    return View(model); 
} 

Answer 2

La diferencia entre MVC y MVVM es que MVC tiene un conjunto de clases para las entidades de datos. En MVVM tiene 2: un conjunto para vincular sus vistas y otro para administrar la persistencia de los datos (que podría estar en un servicio separado de WCF, por ejemplo).

Las ventajas de MVVM son que el modelo vinculado a las vistas es relevante para la interfaz de usuario y completamente independiente del modelo de persistencia.

¿Qué usar? Bueno, depende de qué tan cerca la estructura de datos requerida por sus Vistas se mapee a la estructura de la base de datos. Cuando es similar, es posible enlazar los DataEntities de su DAL directamente a su vista, este es el patrón clásico de MVC. Sin embargo, gana mucho con un ViewModel por separado, ya que puede ampliar estas clases con el comportamiento específico de View (por ejemplo, Validation) que su DAL no debería preocuparse.

Para todas las aplicaciones menos las más simples, recomendaría el uso de un ViewModel por separado.