Оооо .... так много вредных привычек.
Часть 2. Оптимизация В недалеком прошлом, в дни ADO.Net, я обычно писал хранимые процедуры, выполнял их через DataReader изатем переберите DataReader, заполните столько объектов моего класса Model и передайте эту коллекцию для привязки к DataGrid.В дни LINQ я делаю более или менее то же самое, что касается создания коллекции объектов.Но я сам выполняю прямые операторы LINQ.Я могу предположить, что хранимые процедуры SQL дадут мне более высокую производительность, но
По сути, в прошлом у вас были некоторые небольшие заблуждения.Хранимые процедуры НЕТ (!) Прироста производительности уже более 10 лет.Это четко прописано в документации.Выполнение SQL выполняется так же быстро, как и для не хранимых процедур, планы запросов кэшируются и используются повторно для обоих.
SP эффективны (например, экономия времени), если они избегают циклических переходов (то есть отправка нескольких пакетов запросов изклиент от сервера).И тогда экономия происходит не благодаря тому, что они являются запутанными процедурами, а благодаря тому, что поездки туда-обратно стоят времени.
К сожалению, у многих программистов все еще есть заблуждения, потому что они получают их от других людей, которые их получили..... 10 лет назад, когда хранимые процедуры имели внутренние преимущества.Теперь, когда это время SQL Server 6.5 - с 7.0 это уже история.
http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx
В основном вы рассматривали потерянное время разработки и множество бесполезного кода против ... по всей вероятности, не измеримого преимущества.
Часть 1. Пулы и оптимизация соединений. Я хочу знать, как я могу гарантировать, что LINQ устанавливает только одно соединение с базой данных, а также следит за пулами соединений.
Вы не можете,По сути, не пытайтесь быть умнее, чем полезно для вас.Что не так с несколькими соединениями, ЕСЛИ ОНИ СМЫСЛИ?
Для объединения в пул, yu (сервер sql) не нужно помещать что-либо в строку подключения нормально.И да, LINQ не будет магически обходить пул соединений, определенный в строке соединения.Понимаете, LINQ НИКОГДА не общается с базой данных - для этого он использует ADO.NET, а ADO.NET не изменил магическим образом поведение только потому, что какой-то ORM более высокого уровня использует его вместо вас.Строка подключения содержит записи пула, ADO.NET по-прежнему видит их и следует за ними.
Теперь наличие только одного подключения к базе данных из пула серверов - это одно: STUPID.Он ограничивает одну транзакцию за раз и полностью снижает производительность, как только нагрузка становится выше (т.е. необходимо обрабатывать несколько запросов одновременно).
Я использую объект DataContext в «использовании»блок в моем коде, где я обрабатываю данные, связанные с частью.Это причина, почему LINQ может использовать несколько соединений?Если у меня есть DataContext как переменная уровня класса, это обеспечит только одно соединение?
Ах - зависит.Это может иметь смысл, а может и нет.Вы знаете, прежде чем думать, что у вас есть проблема, особенно учитывая огромное количество информации, которую вы здесь даете (т.е. ни одной), сделайте ЕДИНСТВЕННУЮ разумную вещь: возьмите профиль и ИЗМЕРИТЕ, есть ли у вас.Открытие / закрытие соединения 100 или 1000 раз, скорее всего, даже не будет отображаться в профиле. Нет проблем = нет причин что-то исправлять.
Тем не менее, мне не нравится открытие соединения по методу - обычно этопоказывает плохой дизайн класса.Соединения следует повторно использовать в единице работы.