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

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

 Brett Rigby13 июл. 2012 г., 15:35
Я ценю, что этот вопрос был задан некоторое время назад, но мне любопытно, что вы в конечном итоге решили по ситуации POCO против STE?

Ответы на вопрос(4)

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

Решение Вопроса

ция DataSet.

В приложении ASP.NET вам нужно будет хранить STE где-то среди запросов. В первом запросе вы запросите свой источник данных, чтобы получить STE и предоставить данные на странице. В следующем запросе (постбэке) вы захотите изменить STE на возвращенные данные из браузера. Для поддержки отслеживания вам нужно будет использовать тот же STE, что и в первом запросе =>, вам нужно будет хранить STE в viewstate (если вы хотите использовать ASP.NET WebForms) или сеансе.STE бесполезен для SOA или взаимодействия. Логика отслеживания является частью STE = она работает на клиенте. Если вы предоставляете STE в сервисе, вы сразу же ожидаете, что клиентская сторона будет использовать те же функции отслеживания, которые включены в логику STE. Но эти функции не предоставляются другой стороне автоматически. В .NET они у вас есть, потому что вы делитесь сборкой с STE. Но на другой платформе вы должны объяснить разработчикам, как реализовать логику STE, чтобы она работала на вашей стороне. Это будет, пожалуй, самый ограничительный случай для вас из-за приложения iPhone.
 Daniel Auger28 сент. 2010 г., 21:09
«STE бесполезен для SOA или взаимодействия». Я полностью согласен. К сожалению, люди настаивают на том, чтобы рассматривать SOA и WCF как удаленное взаимодействие. Конечно, это МОЖЕТ быть сделано, но тогда вы очень доверяете клиенту.
 Ladislav Mrnka28 сент. 2010 г., 20:49
Если вас устраивает дополнительный запрос к базе данных, вам вообще не нужен STE - кроме модификации графов сложных объектов. Вы можете позволить ObjectContext (с прокси POCO) отслеживать изменения за вас.
 Jonathan Escobedo16 апр. 2011 г., 16:59
Возможно, STE - не лучший выбор для сценариев ASP.Net, вы могли бы использовать DTO, ориентированный на получение более несвязанного решения, особенно для его возможностей взаимодействия (SOA).
 Felipe Fujiy Pessoto28 сент. 2010 г., 20:44
В ASP.NET, почему бы просто не показать STE при первом запросе, а при обратной передаче получить STE из базы данных, обновить поля и сохранить?
 Brett Rigby13 июл. 2012 г., 15:34
Может быть, это только я, но, безусловно, действия на уровне доступа к данным ограничены собой и, возможно, бизнес-уровнем выше; Я хотел бы думать, что ViewModels (или тому подобное) используются при представлении данных слоям выше в стеке, абстрагируя сложности слоя данных от любого клиентского приложения или других потребителей. Мои веб-приложения (ASP .Net или MVC) совершенно не знают о STE, который я использовал ниже, так как не вижу смысла делать прямую ссылку в моем n-уровневом приложении с веб-слоя вверху вниз по данным. / моделировать слои, где определены STE.
 John Farrell29 сент. 2010 г., 00:24
@ Ладислав Мрнка - Я изменил это. Возможно, пользователь не хотел пометить это MVC. Я не хотел, чтобы пользователь боялся использовать STE из-за технологического стека, который он не использовал.
 Ladislav Mrnka28 сент. 2010 г., 21:36
@jfar: Lol. Это причина для понижения? Тебе не кажется, что это повод для разъяснений от Кумара? Тэг говорит, что это MVC, и вопрос касается ASP.NET 4.0 и будущего расширения для iPhone. Упоминание состояния и совместимости вполне законно.
 John Farrell28 сент. 2010 г., 21:24
Хотя этот ответ технически правильный, пользователь ничего не сказал о SOA и использует MVC, поэтому любые проблемы ViewState неуместны.

eb с WCF. Я участвовал в двух проектах, используя их (один в производстве, один почти).

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

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

 Baig02 авг. 2011 г., 14:01
@jfar, в сценарии WCF понятие «Независимые от платформы службы» теряется, если вы используете STE (a.k.a Self Tracking Entities). Например, что если существует клиентское приложение Java, которое хочет взаимодействовать со службой WCF. Как клиентское приложение Java получит наборы на стороне клиента? К сожалению, это просто не может! Значит, если мы используем STE, то наша служба WCF может использоваться только клиентами, встроенными в .Net. Что ужасно, не правда ли?
 Paul Hiles19 янв. 2011 г., 13:42
Как вы сохраняете свой STE между запросами (например, GET -> POST)?

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

Ваш ответ на вопрос