Обновление MVC2 Poco, когда свойства не сопоставлены с моделью представления

Мне нужны некоторые мнения и лучшие практики для обработки обновлений моего репозитория в следующем сценарии:

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

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

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

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

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

ИЛИ есть ли еще что-то, что мне не хватает.

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

Спасибо


viewmodel asp.net-mvc-2 poco
person nixon    schedule 20.01.2011    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

TryUpdateModel(customer, "Customer");

Где клиент — это только что прочитанный клиент, а «Клиент» — это имя свойства в модели представления.

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

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

person nixon    schedule 20.01.2011