Более эффективный доступ к базе данных - PullRequest
Новая
       21

Более эффективный доступ к базе данных

3 голосов
/ 16 января 2011

Я новичок в базах данных и linq, поэтому мою проблему можно считать тривиальной. В настоящее время я запускаю все свои запросы к базе данных в каждом классе с: 

 DataClassesDataContext db = new DataClassesDataContext()

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

Теперь два интересных запроса:

1) Мне кажется, я видел людей, которые оборачивали использование БД в «использование». Такие как: 

using (DataClassesDataContext db = new DataClassesDataContext())
{
    ...
}

Если это правильно, то не означает ли это, что мой класс больше не может использовать переменную-член 'db', а эти запросы к db необходимо выполнять в каждом вызове функции? Кроме того, что именно произойдет, если я не буду использовать «использование» в вызовах?

2) Запустив мое приложение с включенным SQL Profiler, я вижу множество соединений, открывающихся и закрывающихся. Означает ли это, что каждый вызов DataClassesDataContext создает отдельное соединение? Это кажется неэффективным, поэтому правильный ли способ сделать объект DataClassesDataContext статическим в каждом используемом классе?

Ответы [ 2 ]

1 голос
/ 16 января 2011

Поскольку вы добавили тег asp.net, это означает, что вы используете контекст в вызове HTTP. Статический контекст члена неприменим в asp.net, потому что вам нужно синхронизировать доступ к нему, а поскольку ваш контекст данных требуется для каждого вызова, вы можете одновременно обслуживать только один HTTP-ответ, фиаско масштабируемости эпических пропорций.

Вот почему контекст данных создается и размещается «на ходу». Фактически, спецификация класса явно вызывает этот шаблон использования:

В общем случае экземпляр DataContext рассчитан на одну единицу работа "однако ваше приложение определяет этот термин. DataContext - это легкий и не дорогой Создайте. Типичный LINQ to SQL приложение создает DataContext экземпляры в области видимости метода или как член недолговечных классов, которые представляют собой логический набор связанных операции с базой данных.

Для ASP.Net разумным контекстом «единицы работы» является сам HTTP-вызов. Более подробное обсуждение этой темы можно найти по адресу Linq to SQL DataContext Lifetime Management .

Проблема открытия / закрытия соединений не является проблемой. Обычно соединения объединяются, и «открытие» - это не что иное, как повторное использование соединения из пула. Если вы открываете тяжеловесный (полноценный логин), то вы используете пул неправильно. Сравнение Логинов / сек и Сброс подключения / сек. Счетчики быстро покажут, если это действительно так.

1 голос
/ 16 января 2011

Как правило, вы должны использовать один DataContext для каждой беседы с базой данных.Только вы можете точно определить, что такое разговор, но обычно это полный запрос (например, получение списка пожеланий пользователя или получение закрытых заказов пользователя), который вы можете рассматривать как «единицу работы».

Как правило, что происходит примерно так: 

WishList wishlist;
using(var context = new DataContext(connectionString)) {
    var service = new UserWishListService(context);
    wishlist = service.GetUserWishList();
}

Кроме того, что именно произойдет, если я не использую using в вызовах?

DataContext не будет утилизирован должным образом (если вы не завернули в try-catch-finally, но обычно вы должны просто использовать using).

Означает ли это, что каждый DataClassesDataContext Вызовите отдельное соединение?

Не совсем.Ваше приложение получит выгоду от встроенного пула соединений поставщика SQL Server ADO.NET .Не беспокойтесь об этом, позвольте провайдеру управлять им за вас.

Это кажется неэффективным, так что это правильный способ сделать объект DataClassesDataContext static в каждом используемом классе.?

Абсолютно нет.DataContext s не являются поточно-ориентированными (на самом деле они поточно-небезопасными), и на них написано "там будут драконы".Кроме того, даже однопоточный контекст, static DataContext является плохим выбором, поскольку DataContext поддерживает кэш (для целей отслеживания объектов) всех сущностей, которые он извлек из базы данных.Со временем потребление памяти станет огромным.

...