При взгляде на веб-сайт Microsoft я обнаружил, что они больше не рекомендуют использовать Self-Tracking Entities.
Каждая ссылка ниже представляет собой ресурс MS, в котором упоминается не использование STE:
Показывает, какие шаблоны доступны для команды Entity Framework: Шаблоны генерации кода конструктора EF
Кто-нибудь знает, почему Microsoft больше не рекомендует использовать STE?
(ПРИМЕЧАНИЕ. Поскольку я не работаю для MS, это все предположение, основанное на их публичных заявлениях и прошлой истории).
В первой статье, которую вы опубликовали "своего рода", объясняется причина, хотя и не очень четко: они хотят, чтобы вы использовали лучшую альтернативу и не намерены исправлять или улучшать STE. Microsoft помещает STE в корзину "ранних неудачных экспериментов", подобно RDO или Remoting или LINQ2SQL, - они что-то выставляют, чтобы понять, как хорошо это работает, и просто этого не произошло.
В целом, Microsoft всегда признавала, что STE были первыми, кто пытался решить настоящую деловую проблему, но что они были явно неполными. В частности, они были очень плохие при прикреплении графиков объектов с общими объектами, они не поддерживали ленивую загрузку и имели ряд других разных ограничений.
MS, по-видимому, решила, что они не собираются пытаться их очистить (обратите внимание, что они также устарели шаблон POCO по аналогичным причинам). Поскольку они не планируют исправлять или улучшать шаблон, они хотят, чтобы люди перестали использовать его для новых проектов и перешли к лучшим альтернативам:
Генератор DbContext
Этот шаблон будет генерировать простые классы сущностей POCO и контекст, который происходит из DbContext. Это рекомендуемый шаблон, если у вас нет причин использовать один из других шаблонов, перечисленных ниже.
STE существовали в основном для поддержки случаев, когда объекты были отключены и повторно подключены к их контексту, особенно в сценариях сериализации (например, WCF или веб-сервисы). В "стандартных" объектах Entity Framework все отслеживание изменений было выполнено в контексте, а привязка существующего объекта к контексту была проблематичной. STE сделали этот процесс более легким, но ценой практически сделать все остальное.
Из того, что я видел и переживал о DbContext, он должен быть лучшей альтернативой для решения этой проблемы, хотя на самом деле он не реплицирует то, что делали STE. Общий консенсус среди тяжелых пользователей EF, по-видимому, заключается в том, что сериализация ваших EF-объектов сквозная - это действительно плохая идея. Вместо этого вы должны использовать DTO и что-то вроде AutoMapper для сопоставления между объектами DTO и EF.
Я создал Trackable Entities в качестве замены для STE: https://trackable.codeplex.com. Он развертывается как набор пакетов NuGet и расширения Visual Studio. Существует набор шаблонов проектов с шаблонами T4 для ASP.NET Web API, а также шаблоны элементов для создания служб WCF.
Вот сообщение в блоге, которое я написал, сравнивая TE с STE: http://blog.tonysneed.com/2013/11/18/trackable-entities-versus-self-tracking-entities.
Cheers, Тони Снед