Linq to SQL: лучше ли иметь маленький DataContext для каждой страницы или глобальный?

Question

Я пробую Linq to SQL в приложении ASP.NET, которое использует большую базу данных с большим количеством внешних ключей (более 100 таблиц). Я впечатлен тем, как Linq позволяет вам создавать текстовые данные со всеми вашими отношениями без изменений, а затем создавать операторы Linq, которые автоматически объединяют таблицы. Однако это приводит к вопросу: если я отправляю оператор Linq, который работает только с одной или двумя таблицами, лучше ли иметь текстовый текст, в котором просто есть необходимая таблица / таблицы? Мне кажется, что если я создам текстовый текстовый код со всеми таблицами в базе данных, он будет довольно массивным, и загрузка его для каждого использования Linq окажет негативное влияние на производительность. Я прав?

Комментарий: я знаю, что создавать текстовые данные нужно только по мере необходимости (но, тем не менее, спасибо, что упомянули его). Вопрос действительно в том, должно ли у меня быть много маленьких Dacacontexts или было бы хорошо создать один большой.

Answer 1

У вас должен быть один DataContext на одну группу связанных таблиц. В большинстве приложений это означает один DataContext для всего. Если у вас есть несколько наборов таблиц, которые вам не нужно изменять вместе, вы можете рассмотреть несколько DataContexts. Если вам даже может потребоваться выполнить запрос через DataContexts, не разделяйте их.

DataContext - это не просто набор таблиц - он предназначен для реализации шаблона Data Gateway - вы можете заполнить его методами, которые возвращают нужные вам данные, поэтому вам не нужно жестко кодировать запросы в каждом уголок вашего приложения. Теперь, если бы у вас было несколько DataContexts, по одному на страницу, вам, скорее всего, пришлось бы встраивать свою общую функциональность (например, MyDataContext.GetActiveCustomers ()) в каждую из них. Это было бы ужасным дублированием.

Таким образом, ответ таков: обычно неправильно создавать много маленьких DataContexts. Это возможно только в том случае, если ваши данные полностью разделены (разные логические или физические базы данных) или если вы используете DataContext в качестве просто объекта Connection, а это не так.

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

Answer 2

На этой странице http://www.albahari.com/nutshell/10linqmyths.aspx (см. Миф # 10) сказано, что лучше использовать кратковременные экземпляры DataContext.

Answer 3

Я провел тест в нашей базе данных, которая насчитывает около 600 таблиц. Во-первых, я разбил их на 9 отдельных контекстов данных, каждый из которых был довольно управляемым. Затем я написал скрипт, который выбирал, обновлял и удалял несколько сотен раз на одном из них (избавляясь от текста данных после каждого, так что LINQ был вынужден пересоздавать его для каждого доступа).

Затем я сделал еще один текстовый текст, в котором были все 600 таблиц, и провел тот же тест.

Результаты были практически идентичны. Я пришел к выводу, что при меньших значениях данных не было никакого увеличения производительности. И, конечно, гораздо проще работать с сущностями, которые взяты из одного текста данных (хотя и не в дизайнерском представлении - фу!).

Answer 4

Я считаю, что контекст данных довольно легкий, в основном это просто контейнеры. Данные на самом деле не загружаются в контекст, пока вы не запросите их. Я не думаю, что было бы неправильно иметь единый контекст данных, а только создавать его по мере необходимости (как единицу работы), а не хранить его постоянно. Таким образом, у вас нет долгоживущего объекта, который может продолжать расти все больше и больше.

Если ваши таблицы можно разделить на связанные группы таблиц, вы можете рассмотреть возможность создания отдельного контекста данных для каждой из этих групп. Я не уверен, как LINQ будет обрабатывать запрос, используя данные из разных контекстов, но кажется, что он должен работать, пока таблицы находятся на одном сервере. Вам придется проверить это, если вы разбили вещи на несколько контекстов и имели запросы, для которых требовались таблицы из более чем одного.

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