Есть ли причина превращать POCO в объекты Model?

Question

Если я генерирую объекты POCO из EntityFramework и использую их для перехода на / с сервера WCF, есть ли какая-либо причина для создания клиентских моделей для использования в представлениях и моделях представления вместо простого использования POCO?

Почти все примеры MVVM, на которые я смотрел, привязывались прямо к объекту, возвращенному из службы WCF. Это хорошая практика? Можно ли привести аргументы для фактического сопоставления POCO с Моделью и работы View / ViewModels с объектом Model вместо POCO?

Основная причина, о которой я мог подумать, это валидация, однако, поскольку POCO EF являются частичными классами, их можно расширить, чтобы включить валидацию.

РЕДАКТИРОВАТЬ

Большинство ответов до сих пор приводят INotifyPropertyChanged в качестве основной причины для построения отдельной Модели. Изменится ли ваш ответ, если вы используете самоконтрольные объекты вместо POCO, которые уже включают INotifyPropertyChanged? STE также являются частичными классами, которые могут быть расширены для включения проверки.

Answer 1

Валидация является основной причиной не связываться напрямую с POCO.Кроме того, если POCO еще не реализует INotifyPropertyChanged и другие необходимые интерфейсы, опыт работы с объектом на стороне WPF может быть менее желательным, и реализация ViewModel для переноса этого имеет смысл.

Предоставление ViewModel для обертывания вашего POCO позволяет вам инкапсулировать логику в ICommand реализации, а также аккуратно реализовать необходимые интерфейсы.

Answer 2

Я немного не согласен с Ридом (это, конечно, необычное обстоятельство).Я бы НЕ реализовывал ViewModel, чтобы обернуть POCO.Я бы реализовал класс Model, чтобы обернуть POCO и открыть Модели для ViewModel через слой Service.

Основная задача ViewModel состоит в том, чтобы надлежащим образом представлять данные Model в View и реагировать на его запросы.Архитектура, над которой я сейчас работаю, выглядит следующим образом:

• 1 ViewModel для каждого View
• ViewModel вызывает объект уровня Data Service для получения экземпляров модели (не путатьсо службой WCF)
• Уровень службы данных отправляет соответствующие запросы CRUD бэкэнду (для этого используются службы WCF, RIA или RESTful для Silverlight, но могут быть ADO.NET или EF напрямую для WPF).
• Служба данных использует возвращенные POCO для создания объектов Model.
• Объекты Model обертывают объект POCO и реализуют INotifyPropertyChanged.Объекты модели обеспечивают соблюдение бизнес-правил.

Я все еще прорабатываю детали, но в ближайшем будущем я опубликую что-то более конкретное.

Answer 3

Мои модели принимают объект WCF, который предоставляет те свойства, которые я хочу использовать в моей ViewModel. Затем я могу также расширить объект по мере необходимости. Мои свойства указывают на свойство объекта WCF, и когда мне нужно отправить объект обратно в службу WCF, мне больше не нужно выполнять какую-либо работу. Модели наследуют INotifyPropertyChanged и INotifyDataErrorInfo , которых у DTO (упомянутых здесь как POCO) не будет. Ваша бизнес-логика / валидация существует в вашем приложении Silverlight, а не в вашей службе WCF.

Вид связывается с ViewModel, у которого есть Модель (или наблюдаемая коллекция Моделей). Модели имеют объект WFCObject, который является DTO (упоминается здесь как POCO). Я использую свою ViewModel для связи со службой, MVVM Light предлагает модели для связи со службой / провайдером, что мне не нравится.

Answer 4

Привязка к EF POCO, если вы хотите сделать простой CRUD или хотите сделать что-то быстрое.

В противном случае ваши серверные модели будут очень тесно связаны с базой данных, которая меняется очень медленно по сравнению с пользовательским интерфейсом. Для менее тривиального пользовательского интерфейса вы обнаружите, что добавляете все больше и больше кладжей просто для того, чтобы приспособить модель вашей базы данных к пользовательскому интерфейсу (или иначе, что еще хуже).

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

См. Также http://ayende.com/Blog/archive/2010/08/06/data-access-is-contextual-a-generic-approach-will-fail.aspx

Answer 5

POCO Рэйчел - просто тупые объекты, сгенерированные EF и используемые для транспорта (DTO). Поэтому у них не должно быть других вещей, загромождающих их область. Это очень хороший способ разработки вашего кода, поскольку он отделяет любые требования на стороне клиента от требований на стороне сервера. Вот почему существует MVVM - для расширения модели MVC, включающей эти проблемы.

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