Экономит ли время повторное использование соединения с БД с помощью EF 6 DbContexts?

#.net #database #entity-framework #entity-framework-6 #dbcontext

#.net #База данных #entity-framework #entity-framework-6 #dbcontext

Вопрос:

Мой код усеян using блоками, которые создают экземпляры, используют и удаляют DbContext объект. Улучшит ли это производительность, если я передам открытое соединение конструкторам этих объектов, или объединение пулов соединений сделает для меня достаточно работы на этом фронте?

1. Если вы используете так много контекстов, вы все равно неправильно используете EF. Обычно у вас должен быть один контекст для каждого запроса и общий доступ ко всей объектной модели для всего, что делает запрос.

2. Хотя я и не использую «по запросу», я использую только один DbContext для каждого запроса, и он должен открывать свое собственное или объединенное, или, если нет объединения, общее соединение. Это часто случается.

Ответ №1:

Это будет зависеть от системы базы данных, к которой вы обращаетесь, и от того, ADO.NET поставщик поддерживает объединение пулов соединений для этой конкретной системы баз данных.

Ответ на ваш вопрос: для SQL Server — нет, но для SQL Server Compact — да.

1. Вы не можете утверждать, что ADO.NET не поддерживает объединение пулов соединений для SQL Server? Должно быть, я вас как-то неправильно понимаю.

2. Я отвечал на ваш вопрос, ответ уточнен / обновлен.

Ответ №2:

Если ваш провайдер поддерживает это, по моему опыту, объединение пулов соединений справляется с этим достаточно хорошо. Если вы считаете, что это узкое место, вам, конечно, следует провести тест.

Размышляя подобным образом, я однажды создал класс, подобный этому:

 class Foo
{
    SqlConnection con;
    SqlCommand cmd1, cmd2;

    void DoStuff();

    static Foo GetFoo() { get from cache, or create a new one. }
}

Вместо того, чтобы создавать новый каждый запрос, я поддерживал соединения открытыми, а команды готовыми к действию, кэшируя весь Foo объект. К сожалению, это лишь незначительно улучшило производительность SQL Server.

В вашем случае есть целый другой уровень Entity Framework, поэтому ваше общее улучшение будет еще менее значительным. В общем, я предполагаю, что если вы используете EF, вам в первую очередь не требуется высокая производительность, поэтому дополнительная сложность при таком небольшом выигрыше, вероятно, того не стоит.