Самостоятельно отслеживаемые объекты против объектов POCO - PullRequest
Новая
       34

Самостоятельно отслеживаемые объекты против объектов POCO

31 голосов
/ 28 сентября 2010

Мы запускаем новый веб-продукт, в котором мы планируем раскрыть нашу бизнес-логику с помощью сервисов WCF.Мы будем использовать ASP.NET 4.0, C #, EF 4.0.В будущем мы хотим создавать приложения для iphone и WPF на основе сервисов.Я много читал об использовании POCO против объектов самообследования (STE), и, насколько я понимаю, STE плохо работают с веб-сценарием.Кто-нибудь может пролить больше света на этот вопрос?

Ответы [ 4 ]

36 голосов
/ 28 сентября 2010

Для меня STE - абсолютно неверное понятие.Это просто еще одна реализация DataSet.

  • В приложении ASP.NET вам придется хранить STE где-то среди запросов.В первом запросе вы запросите свой источник данных, чтобы получить STE и предоставить данные на странице.В следующем запросе (постбэке) вы захотите изменить STE на возвращенные данные из браузера.Для поддержки отслеживания вам нужно будет использовать тот же STE, что и в первом запросе =>, вам нужно будет хранить STE в viewstate (если вы хотите использовать ASP.NET WebForms) или сеанс.
  • STE бесполезен для SOA или взаимодействия.Логика отслеживания является частью STE = она работает на клиенте.Если вы предоставляете STE в сервисе, вы сразу же ожидаете, что клиентская сторона будет использовать те же функции отслеживания, которые включены в логику STE.Но эти функции не предоставляются другой стороне автоматически.В .NET они у вас есть, потому что вы делитесь сборкой с STE.Но на другой платформе вы должны объяснить разработчикам, как реализовать логику STE, чтобы она работала на вашей стороне.Это будет, пожалуй, самый ограничительный случай для вас из-за приложения iPhone.
8 голосов
/ 28 сентября 2010

Объекты самообследования отлично работают в сценарии MVC Web с WCF. Я участвовал в двух проектах, использующих их (один в производстве, один почти).

С POCO вы потеряете любое отслеживание изменений по проводам, что создает много дополнительной боли, потому что EF теперь приходится повторно запрашивать информацию о состоянии. Если вы используете EF и WCF STE, вы решите много проблем и сделаете весь конвейер персистентности действительно гладким.

Можете ли вы привести цитату по этой претензии? «STE плохо работают с веб-сценарием»

3 голосов
/ 30 октября 2012

См. http://msdn.microsoft.com/en-us/data/jj613924.aspx,, так как STE больше не рекомендуется!Microsoft рекомендует использовать любой из API-интерфейсов ASP.NET Web API, WCF Data Services или Entity Framework API (сложные операции)

2 голосов
/ 29 сентября 2010

Если эта служба будет использоваться любым приложением, над которым у вас нет прямого контроля, вам, вероятно, следует подумать о том, чтобы отделить что-либо, имеющее отношение к EF (или nHibernate, Linq2Sql или любому другому решению для управления сохранением данных), от ваших служби ваши объекты передачи данных.Это защитит внутренние изменения от взлома клиентов.Взломать клиентов, как правило, плохо.

...