Мне было интересно, использует ли кеш LINQ to SQL DataContextWeakReference или подобную систему, чтобы избежать слишком много памяти после нескольких запросов?LinqToSql Использование кэша и использования памяти DataContext
Относится ли это к ObjectTrackingEnabled?
Нет; он использует регулярные ссылки, поскольку, как правило, он должен поддерживать объекты для отслеживания изменений (как вы упоминаете), но также для работы менеджера идентификации.
Это, однако, не проблема - потому что вы должны использовать экземпляр DataContext в качестве единицы работы. Поскольку в противном случае накладные расходы диспетчера изменений/идентификаторов-менеджеров вскоре сделают контекст данных полностью раздутым и непригодным (слишком медленным).
So; просто используйте контекст данных кратко, и пусть объекты будут собраны после завершения вашей операции. Не держите содержимое контекста данных произвольно.
Иногда вам вообще не нужен контекст данных; для приложений с преобладанием чтения существуют альтернативные, но похожие механизмы запросов.
Можете ли вы привести пример альтернативного, но похожего механизма запросов? – bzlm
@bzlm существует, чтобы использовать термин, который имеет смешанный смысл для разных людей, «микро ORM», такие как dapper-dot-net, PetaPoco, массив и Simple.Data, которые могут быть очень полезными. Я участвую в dapper (-dot-net), и мы написали его специально, чтобы позволить нам повторно использовать наши классы LINQ-to-SQL, но без накладных расходов L2S. –
Thx, я уже должен использовать PetaPoco в стороне моего L2S DataContext. Я немного разочарован в этом поведении, я знаю о единице работы, которую мы должны использовать, но если вы не можете делиться (легко) IQueryables или Entities между разными экземплярами, в некоторых случаях он становится бесполезным (по крайней мере, для меня). Для проблемы IQueryable, я думаю, я попытаюсь заменить их параметрами Linq.Expression <>. – Guillaume86