Путать с моделью против ViewModel

21

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

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

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

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

  • MyCompany.Entities.dll(все модели идут здесь) EG Product
  • MyCompany.Dal.dll(все репозитории идут сюда)
  • MyCompany.Services.dll(вызываемый MyCompany.WebUI.Controller вызывает MyCompany.Dal)
  • MyCompany.WebUI.MyApp
  • MyCompany.Tests

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

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

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? Что такое стандарт?

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

Теги:
asp.net-mvc
asp.net-mvc-3

2 ответа

30
Лучший ответ

Используйте ViewModels, чтобы упростить просмотр.

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

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

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

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

С помощью инструмента, такого как AutoMapper, легко перемещаться между вашими проекциями ViewModels и моделями домена.

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

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

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

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

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
    Привет, спасибо за ваш ответ, вы говорите: у нас нет моделей внутри нашего webApp. У нас есть ViewModel, на которые ссылаются контроллеры, и затем мы внедряем «Модель» домена в viewModel, чтобы мы могли добавлять аннотации и проверку к нашему ViewModels. У вас есть быстрый пример где-нибудь или ссылка наша структурирована? Я был бы очень признателен. Спасибо
  • 1
    Это именно то , что я говорю - молодец, суммируя это в одном предложении. Теперь, конечно, вашему веб-приложению все еще нужно будет ссылаться на сборку модели домена, поскольку оно должно отображаться между ними. Но главное, что ваши представления не имеют представления о ваших моделях доменов, они привязаны к моделям представления. Достойный пример здесь: weblogs.asp.net/shijuvarghese/archive/2010/02/01/… . Просто гуглите вокруг "asp.net mvc view pattern pattern"
Показать ещё 2 комментария
1

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

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

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

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

Поделиться
  • 0
    Привет, спасибо за ваш ответ. Мои представления не будут иметь представления о базе данных. Они будут называть «ViewModels», а те - сервисный уровень, а оттуда - DAL. Все через интерфейсы. Из того, что вы говорите, MVVM на самом деле является шаблоном для использования в MVC. Это то, что вы говорите?
  • 0
    Извините - мое последнее предложение перепутано - я не имел в виду, что Views ссылается на базу данных - я обновлю. Я имел в виду, насколько близко структура, требуемая во ViewModel, совпадает с той, что используется в базе данных. Но в ответ на ваш вопрос - да - в вашем случае ViewModel был бы моим выбором.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню