Если я создаю объекты POCO из EntityFramework и используя их для перехода на/с сервера WCF, есть ли причина создавать модели на стороне клиента для Views и ViewModels для использования вместо прямого использования POCO?
Почти все примеры MVVM я посмотрел на привязку прямо к объекту, возвращенному из службы WCF. Это хорошая практика? Существуют ли аргументы, которые могут быть сделаны для фактического сопоставления POCO с моделью и использования /ViewModels, работающих с объектом Model, вместо POCO?
Основная причина, по которой я могу думать, - это проверка, однако, поскольку EF POCOs являются частичными классами, их можно расширить, включив проверку.
EDIT
Большинство ответов до сих пор приводили INotifyPropertyChanged в качестве основной причины для создания отдельной Модели. Изменяется ли ваш ответ, если вы используете объекты самоконтроля вместо POCO, которые уже включают INotifyPropertyChanged? STE также являются частичными классами, которые могут быть расширены для включения проверки.
Валидация является основной причиной не связывания напрямую с POCO. Кроме того, если POCO еще не реализует INotifyPropertyChanged и другие необходимые интерфейсы, опыт работы с объектом на стороне WPF может быть менее желательным, и внедрение ViewModel для его обертывания имеет смысл.
Предоставление ViewModel для упаковки вашего POCO позволяет инкапсулировать логику в реализацию ICommand, а также реализовать необходимые интерфейсы.
Я не согласен только с Ридом (это необычное обстоятельство). Я бы не реализовал ViewModel для обертывания POCO. Я бы выполнил класс Model, чтобы обернуть POCO и подвергнуть модели ViewModel с помощью уровня сервиса.
Основное задание ViewModel заключается в том, чтобы соответствующим образом представить данные модели в представление и отреагировать на его запросы. Архитектура, над которой я работаю, выглядит так:
Я все еще работаю над деталями, но в ближайшее время я опубликую что-то более конкретное.
Мои модели принимают объект WCF, который предоставляет те свойства, которые я хочу использовать в моей модели ViewModel. Затем я также могу расширить объект по мере необходимости. Мои свойства указывают на свойство объекта WCF, и когда мне нужно отправить объект обратно в службу WCF, мне больше не нужно работать. Модели наследуют INotifyPropertyChanged и INotifyDataErrorInfo, которые DTO (упомянутые здесь как POCOs) не будут иметь. Ваша бизнес-логика/validaton существует в вашем приложении Silverlight, а не в вашей службе WCF.
Вид привязывается к ViewModel, который имеет модель (или наблюдаемую коллекцию моделей). Модели имеют WFCObject, который является DTO (упоминается здесь как POCO). Я использую свой ViewModel для связи с сервисом, MVVM Light поддерживает модели с сервисом/провайдером, что мне не нравится.
Rachel POCO - это просто тупые объекты, созданные EF и используемые для транспорта (DTO). Поэтому у них не должно быть других вещей, загромождающих их домен. Это очень хороший способ разработки кода, поскольку он отделяет любые клиентские требования от требований на стороне сервера. Именно поэтому MVVM существует - расширить модель MVC, включающую эти проблемы.
Нет причин, по которым вы не можете привязываться к ним в своих представлениях, если вы не изменяете их напрямую. Вы можете добавить к ним функциональность, добавив частичный класс, но я бы даже этого не сделал. В этом случае вы должны следовать арендаторам проекта MVVM и разделить их на объекты модели, которые удовлетворяют ваши потребности в клиенте. Это будет автоматически автоматизировано после подключения событий INotifyPropertyChanged для уведомления ваших просмотров.
Привяжите к EF POCOs, если вы хотите сделать простой CRUD или хотите что-то сделать быстро.
В противном случае ваши серверные модели будут очень тесно связаны с базой данных, которая изменяется очень медленно по сравнению с пользовательским интерфейсом. Для менее тривиального пользовательского интерфейса вы обнаружите, что вы ставите все больше и больше kludges только для того, чтобы соответствовать вашей модели базы данных в UI (или иначе, что еще хуже).
Кроме того, есть проблемы с производительностью (например, хотите ли вы передать всю сущность, когда для пользовательского интерфейса вам нужно всего лишь несколько свойств?) и проблемы с обслуживанием (например, если вы хотите проверить премиальный заказ клиента совсем не так, как обычно).