Путать с моделью против ViewModel - PullRequest
24 голосов
/ 31 мая 2011

Я изучаю ASP.NET MVC и скачал несколько примеров приложений. MusicStore и т.д ...

Я из фонового wpf, где у нас был шаблон MVVM. Я заметил, что они использовали концепцию модели и ViewModel.

В MVVM довольно ясно, что вы привязываете представление к ViewModel, внедряя модель в viewModel. В MVC у вас есть контроллер, но я не уверен и запутался, как все они связаны друг с другом, так как я не вижу модели, введенной в ViewModel

У меня есть следующая структура

  1. MyCompany.Entities.dll (все модели указаны здесь) EG Product
  2. MyCompany.Dal.dll (все репозитории находятся здесь)
  3. MyCompany.Services.dll (вызывается MyCompany.WebUI.Controller вызывает MyCompany.Dal)
  4. MyCompany.WebUI.MyApp
  5. MyCompany.Tests

Из некоторых примеров, которые я видел, ваша Модель действует как ViewModel. Я прав?

Давайте возьмем контроллер, у меня есть что-то вроде

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
    }
}

Есть ли примеры N-уровня, на которые я могу сослаться? Является ли концепция ViewModel действительной в MVC? Какой стандарт?

Спасибо за любые предложения.

Ответы [ 2 ]

35 голосов
/ 31 мая 2011

Использование ViewModels до упрощение представление.

Например, у вас может быть глубокий граф объектов с продуктами, заказами, клиентами и т. Д., И некоторая информация от каждого из этих объектов требуется для конкретного представления.

ViewModel предоставляет способ агрегирования информации, необходимой для View, в один объект.

ViewModel также допускает такие вещи, как аннотации данных и валидация - что не относится к вашей модели, поскольку ваша модель должна оставаться «специфичной для домена».

Но на самом деле ViewModels - это не более чем простая обертка для ваших доменных объектов.

Используйте такой инструмент, как AutoMapper, для удобного сопоставления моделей ViewModel и моделей доменов.

Лично я всегда связываюсь с ViewModel в моих представлениях, никогда с моделями доменов, даже если это один объект. Зачем? Ну, я люблю украшать мои ViewModels UIHints, валидацией, аннотациями данных. Точно так же, как ваши доменные модели обогащаются специфичными для домена правилами и бизнес-логикой, так что ваши ViewModels должны быть обогащены специфичной для пользовательского интерфейса логикой.

Если у вас просто есть объект с 1-1 представлением модели вашего домена, вам не хватает точки ViewModels.

Добавьте только в ViewModels и не более того, что требуется для определенного View.

Пример действия контроллера

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);
}
2 голосов
/ 31 мая 2011

Разница между MVC и MVVM заключается в том, что MVC имеет один набор классов для объектов данных.В MVVM у вас есть 2 - один набор для привязки к вашим представлениям и один набор для управления сохранением данных (например, в отдельной службе WCF).

Преимущества MVVM заключаются в том, что привязка к моделик представлениям относится к пользовательскому интерфейсу и полностью независим от модели персистентности.

Что использовать?Ну, это зависит от того, насколько точно структура данных, требуемая вашими представлениями, соответствует структуре базы данных.Когда это похоже - можно привязать DataEntities из вашего DAL непосредственно к вашему представлению - это классический шаблон MVC.Тем не менее, вы получаете большую выгоду с отдельной ViewModel, так как вы можете расширить эти классы с помощью особого поведения View (например, валидации), к которому не следует относиться DAL.

Для всех, кроме самых простых приложений, я бы порекомендовал использоватьотдельной ViewModel.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...