Избыточные процессы SQL Server для приложений на основе Entity Framework

Question

В настоящее время мы разрабатываем приложение на основе WPF / Entity-Framework. Одно из наших требований состояло в том, чтобы пользователь мог выбрать, к какой среде (тестирование, обучение или производство) он будет подключаться при входе в систему. Каждый параметр подключения указывает на свою собственную базу данных. Для этого мы создаем новые контексты EF следующим образом:

Public Function NewVectorContext() As VectorEntities
    Dim strDBConn As String = "metadata=res://*/EntityFramework.VectorModel.csdl|res://*/EntityFramework.VectorModel.ssdl|res://*/EntityFramework.VectorModel.msl;provider=System.Data.SqlClient;provider connection string=""" & VectorConnectionString & """"

    Dim EntityConn As System.Data.EntityClient.EntityConnection = New System.Data.EntityClient.EntityConnection(strDBConn)

    Dim MyNewContext as VectorEntities = New VectorEntities(EntityConn)
    MyNewContext.ContextOptions.LazyLoadingEnabled = False

    Return MyNewContext
End Function

VectorConnectionString отформатирован стандартным способом SQL Server:

Data Source=OurDBServer;Initial Catalog=OurAppDB;Persist Security Info=True;User ID=OurUserId;Password=OurPassword

и определяется во время выполнения по выбору пользователя (тестирование, обучение, продукт).

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

Проблема заключается в следующем: когда пользователи используют приложение, мы видим сотни процессов SQL Server в мониторе активности SQL Server. Некоторые отдельные пользователи имеют более 30 процессов, связанных с использованием приложения. Как только пользователь закрывает приложение, все связанные процессы исчезают, но во время работы приложения эти процессы, похоже, остаются.

Answer 1

Исправлено - как я уже упоминал выше, частью решения было правильное управление памятью и обеспечение правильной утилизации всех моделей и моделей. Но это только исключило небольшое количество серверных процессов sql, которые мы видели. Основным виновником был неправильно спроектированный базовый класс модели, который создавал несколько контекстов для каждой создаваемой модели. Как только он был переписан, проблема была решена. Ничего общего с EF.