MVC2 Poco Обновление, когда свойства не сопоставлены с View Model - PullRequest
0 голосов
/ 20 января 2011

Я придерживаюсь некоторых мнений \ передовой практики для обработки обновлений моего хранилища в следующем сценарии:

Я использую EF 4 с шаблонами POCO tt, который создает красивые чистые объекты clr. Например, скажем, у меня есть имя объекта POCO Customer и ViewModel с именем CustomerViewModel. CustomerViewModel имеет открытое свойство для объекта Customer, которое заполняется объектом POCO Customer. Представление ссылается на объект Customer в CustomerViewModel. Все идет нормально. Все отображается как ожидалось.

Когда приходит время обновить CustomerViewModel, выполняется возврат, и заполняются только те свойства, которые были привязаны к представлению, достаточно справедливо.

Теперь у меня есть объект POCO, в котором отсутствуют некоторые значения свойств, которые необходимы для обновления через контекст данных EF. Например, поскольку я не отображал идентификатор в представлении, он не был перенесен обратно в свойство Customer модели представления. Не совсем удивительное поведение, но мне интересно, как лучше всего справиться с этим сценарием.

Итак, вот вопрос: Было бы лучше сопоставить свойства, которые я не отображаю, со скрытыми полями, чтобы у меня был полный объект POCO на обратной передаче, который готов для обновления в хранилище? (Я думаю, что здесь иглы отправляют данные клиенту и обратно)

ИЛИ я должен выполнить чтение Customer перед обновлением (при условии, что у меня есть идентификатор), а затем обновить свойства из моего объекта модели представления. (это иглы для чтения в базе данных?).

ИЛИ есть ли еще кто-то, кого я могу пропустить?

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

Спасибо

1 Ответ

0 голосов
/ 20 января 2011

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

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

TryUpdateModel(customer, "Customer");

Где customer - это недавно прочитанный Customer, а "Customer" - это имя свойства в модели представления.

Похоже, что это приводит к большему количеству доступа к данным, чем в классическом ASP, где объект мог быть помещен (правильно или неправильно) в сеанс!

Кто-нибудь хочет добавить свои 2c?

...