DataModel против DataContract против ViewModel

У меня будет asp.net MVC, который будет подключаться к веб-сервису WCF. Эта служба определяет соединение с базой данных.

Я заметил, что у меня будет 3 разных класса модели/данных.

Во-первых, парень ViewModel из MVC. Я предполагаю, что это может несколько отличаться от того, как данные представлены в БД.

Во-вторых, DataModels, poco, которые определяют, как объекты выглядят в базе данных.

Затем есть парень DataContract, который определяет, как выглядят объекты, передаваемые через службу WCF. Думаю, это будет либо представление ViewModel, либо DataModel.

Это излишество или необходимое зло? Должен ли я определить DataContracts, возможно, как парней ViewModel или даже DataModels.

Как бы вы это сделали и как бы вы разбили его на сборки?


viewmodel entity-framework asp.net-mvc-3 datamodel wcf
person Ingó Vals    schedule 20.09.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

Элементы wcf будут созданы путем ссылки на службу, поэтому они принадлежат вашей службе wcf. Ваша модель данных должна быть в проекте модели или проекте доступа к данным, а ваши ViewModels в вашем приложении MVC, хотя вы можете выйти оттуда, если хотите, но поскольку это довольно тесная связь с приложением MVC, это спорно.

person Adam Tuliper - MSFT    schedule 20.09.2011

arrow_upward
1
arrow_downward

Должен ли я определить DataContracts как парней ViewModel, возможно,

Конечно нет. ViewModels ориентированы на экран (вариант использования).
Но вы можете сделать это в DataService, который используется клиентом SilverLight или jQuery.

или даже модели данных.

Это может иметь смысл. И одна из причин POCO в том, что они могут быть даже одними и теми же классами.

person Henk Holterman    schedule 20.09.2011