Возможные вопросы производительности при использовании Linq to SQL Repositories

Question

У меня есть приложение ASP.NET MVC, которое использует репозитории Linq to SQL для всех взаимодействий с базой данных.

Для обеспечения безопасности данных я выполняю обрезку, чтобы отфильтровать данные только по тем элементам, к которым у пользователя есть доступ. Это происходит в нескольких местах:

1. Данные в представлениях списка
2. Ссылки в строке меню
3. Вид дерева с левой стороны, содержащий ссылки на контент
4. Ролевая безопасность
5. Специальный атрибут безопасности, унаследованный от AuthorizeAttribute, который реализует авторизацию на основе содержимого для каждого метода контроллера.

В каждом из этих мест создается репозиторий, который открывает Linq to Sql DataContext и обращается к базе данных. Итак, по моим подсчетам, каждый запрос на доступ к странице открывает как минимум шесть отдельных Linq to SQL DataContexts.

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

Answer 1

Почти во всех моих приложениях MVC я использую BaseController. Обычно я использую фабрику для создания экземпляра DataContext в конструкторе BaseController (модульные тесты проходят в фиктивном экземпляре фабрики, нулевой конструктор дает экземпляр по умолчанию создаваемой фабрики). Хотя это не является строго необходимым, я удаляю созданный DataContext в OnResultExecuted в BaseController. И контекст данных «по умолчанию», и фабрика представлены как защищенные свойства класса BaseController, поэтому они могут использоваться всеми наследующими контроллерами.

Если мне нужно, чтобы некоторые операции выполнялись за пределами DataContext «по умолчанию», я просто использую фабрику контекста для создания нового отдельного экземпляра по мере необходимости.

Признаюсь, я делаю это в основном для удобства и разборчивости кода. Я думаю, что сами контексты данных достаточно легки, чтобы я не получал много производительности. Однако мне больше не нужно писать код using (var context = ... в каждом методе действия.

Answer 2

Хороший вопрос, я не думаю, что у вас возникнут проблемы больше, чем при обычной работе с запросами. Перевод из выражений Linq в sql-запросы является относительно сложным процессом, но, вероятно, будет бледным по сравнению с фактическим выполнением запроса и задержкой в ​​сети.