Сущность и объекты deataching

Question

При создании веб-приложения, использующего объектную инфраструктуру на своем уровне доступа к данным, рекомендуется отделять объекты от контекста объекта, чтобы объекты могли собираться мусором.

Но поскольку все веб-приложения являются приложениями запроса -> ответа, сам контекст объекта больше не ссылается ни на один из живых объектов после отправки ответа клиенту, поэтому контекст объекта и связанный с ним объект должны быть доступны. для сборки мусора, поскольку ни один из них не ссылается на живой объект.

Я что-то здесь упускаю или отсоединение объектов не нужно в таком сценарии?

Answer 1

Я подозреваю, что в руководстве, которое вы видели, говорилось о запросах без отслеживания

Запросы без отслеживания определенно имеют некоторые преимущества в производительности для сайтов с интенсивным чтением.

Объекты никогда не прикрепляются и отслеживаются по идентичности, поэтому вам не нужно их отсоединять, что позволяет избежать затрат на разрешение идентичности во время материализации.

Запрос без отслеживания выглядит следующим образом:

var source = ctx.Staff;
source.MergeOption == MergeOption.NoTracking;

var staff = (from s in source
             where s.ID == 12 
             select s).First();

Никакие запросы отслеживания не имеют другого преимущества по сравнению с ручным отсоединением сущностей: ручное отключение отключает сущность от остальной части ее графа сущностей, где, так как без запросов на отслеживание вы можете извлечь связанный граф узлов, которые все отсоединены.

Но есть и недостатки в использовании запросов без отслеживания: Иногда вы можете оказаться в ситуациях, когда вы читаете повторяющиеся результаты, потому что вы отключили разрешение идентификаторов.

Так что, если вы действительно не уверены, что ваш запрос будет возвращать только одну копию каждой сущности, вы должны быть осторожны, иначе вы можете получить ошибку пользовательского интерфейса.

Надеюсь, это поможет

Alex

PS: Этот совет о времени жизни ObjectContext может быть полезен для вас.

Answer 2

Предполагая, что вы не сохраняете контекст объекта (удерживая ссылку на него каким-либо образом), как только он выходит из области видимости, он будет собирать мусор. Я не вижу необходимости отделять сущности.

Итак, я не думаю, что вы что-то упускаете.

Answer 3

Эта статья , вероятно, поможет вам. EF был спроектирован как NHibernate с сеансом / контекстом с сохранением состояния по умолчанию (то есть приложение Windows Forms). Возможно, это изменилось с версии 1, когда я в последний раз смотрел на нее. Это немного странно, учитывая, что большинство людей будут использовать его для веб-сайтов - так же, как NHibernate заставляет вас использовать сеанс по запросу и изначально не предназначался для веб-сайтов.

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

Answer 4

В EF, если вам нужно использовать более одного контекста, как в n-уровневом приложении, или если вы хотите создать entityCollection, вам нужно отсоединить сущность. Но это не требовательная реализация для приложения asp.net

Answer 5

Мухаммед, я не могу говорить с EF, но поскольку это относится к Linq-to-SQL, отсоединение объекта не имеет ничего общего с сборкой мусора. Это связано с отсоединением объекта от контекста базы данных, чтобы его можно было присоединить к другому объекту. Это очень распространенная вещь в приложении без состояния (n-уровневое). То же самое может относиться к EF.

Randy