ASP.NET MVC. Должен ли я использовать шаблон репозитория для записи ViewModels в базу данных или сначала преобразовать их в модели?

В моем приложении ASP.NET MVC у меня есть довольно сложная страница редактирования, которая объединяет несколько моделей в одно представление.

Я использую шаблон ViewModel, чтобы объединить всю эту информацию и представить один связанный объект в представлении.

Например, моя структура ViewModel выглядит примерно так:

CompanyId
CompanyName
List<Employee> Employees
List<ContactMethod> ContactMethods

Объект Employee имеет ряд основных свойств и предпочтительный метод связи.

На странице редактирования пользователю предоставляются все сотрудники компании, и у них есть возможность добавлять и удалять (используя javascript), а также редактировать данные о сотрудниках. Список ContactMethods используется для заполнения раскрывающегося списка для каждого сотрудника.

Я успешно перевел свои модели (прочитанные из базы данных) в эту ViewModel и обратно, поэтому после редактирования у меня осталась ViewModel, представляющая текущее состояние сотрудников этой компании.

Я использую шаблон репозитория для связи с базой данных, поэтому мой вопрос: должен ли я вызывать непосредственно в CompanyRepository, передавая ViewModel, или я должен сначала преобразовать ViewModel обратно в объекты модели, прежде чем использовать репозиторий для записи их в базу данных?

Короче говоря, должен ли репозиторий знать о моих объектах ViewModel?


viewmodel repository-pattern c# design-patterns asp.net-mvc
person Damovisa    schedule 16.03.2010    source источник

Ответы (3)


arrow_upward
13
arrow_downward

Я бы сначала преобразовал ViewModel обратно в объекты модели. Мне нравится сохранять зависимость между моим веб-слоем и слоями репозитория как можно более свободной.

Я не думаю, что ваш репозиторий должен знать о вашей ViewModel, поскольку это концепция веб-уровня.

person reustmd    schedule 16.03.2010
comment
Если это так (и это нормально), мне нужно либо создать эти модели сотрудников, удалить всех существующих сотрудников из этой компании, а затем добавить новые модели сотрудников... или... получить все модели сотрудников из базы данных и сопоставьте их перед добавлением, удалением и редактированием, где это необходимо. Это звучит правильно? - person Damovisa; 16.03.2010
comment
@Damovisa: ты можешь это сделать. Вместо этого я бы сохранил эту информацию во время редактирования. В вашей ViewModel поддерживайте три списка: CreatedEmployees, EditedEmployees, DeletedEmployees. - person reustmd; 16.03.2010
comment
@ manu80 - я понимаю, как это может работать, но это может быть немного сложно. Пользовательский интерфейс должен немного измениться, чтобы учесть эти три коллекции, даже если изменится только javascript. - person Damovisa; 16.03.2010
comment
@Damovisa: где-то вам нужно справиться со сложностью. Если вы пойдете своим первоначальным путем, я бы просто уволил всех существующих сотрудников и добавил новых. То есть, если нет реальной добавленной стоимости от добавления сложности вашего второго варианта. - person reustmd; 16.03.2010
comment
@ manu01 manu01 - нет, я согласен с вашим первым предложением - наверное, это правильный путь. В моей (настоящей) системе вполне разумно очистить все дочерние объекты и создать их заново. - person Damovisa; 16.03.2010

arrow_upward
4
arrow_downward

ViewModel — это модель представления (UI), поэтому репозиторий не должен знать о модели представления. Разделение их будет держать репозиторий слабо связанным с пользовательским интерфейсом.

Используйте другой уровень, например сервисный, для инкапсуляции репозитория из пользовательского интерфейса. Этот уровень также выполняет диалог ViewModel-Model и делает вызов репозитория.

public class ServiceLayer
{
   public void SaveModel(ViewModel viewmodel)
   {
      var model = viewModel.ToModel();
      repository.Save(model)
   }
}
person heisthedon    schedule 16.03.2010
comment
Зачем заставлять ServiceLayer зависеть от ViewModel? Вместо этого вызовите viewModel.ToModel на уровне представления, а затем передайте модель службе. - person reustmd; 16.03.2010
comment
@Hery - Да, это звучит хорошо, но это гораздо больше, чем просто передача модели в репозиторий. Модели сотрудников могут быть новыми, измененными или удаленными. - person Damovisa; 16.03.2010
comment
@manu: это просто другой способ реализации, в зависимости от того, как вы хотите инкапсулировать свой репозиторий из представления. Но я могу перечислить некоторые преимущества, такие как: - Выполнение некоторых бизнес-проверок, которые не охватываются преобразованием ToModel. - Держите модель репозитория простой и универсальной, в то время как сервисный уровень выполняет более конкретные задачи, связанные с моделью представления, всего лишь мои 2 цента :) - person heisthedon; 16.03.2010

arrow_upward
1
arrow_downward

Я бы согласился с предыдущим ответом о преобразовании ViewModels обратно в «простые» модели, но добавил бы, что эта задача, вероятно, должна выполняться отдельным сервисным уровнем. Этот уровень будет отвечать за дизассемблирование ваших ViewModels и соответствующие действия.

По сути, это определение службы: нечто, чья работа заключается в выполнении логической единицы работы, требующей нескольких моделей и/или сложной логики.

person Aaron Ransley    schedule 16.03.2010
comment
Я думаю, что эта адаптация должна быть отделена от контроллеров, но я также не думаю, что она помещается в совершенно отдельный слой. Это концепция только слоя просмотра, и она вообще должна попадать в нижние слои. Вы можете просто создать адаптеры или какой-либо вспомогательный класс на том же уровне, что и контроллеры/представления. Я бы сохранил этот сервисный уровень (между репозиторием и уровнем представления) для проверки моделей. - person reustmd; 16.03.2010