Блог

Как часть инструмента профилирования, у меня есть пользовательский ADO.NET стек, который действует как «декоратор» вокруг стандартного ADO.NET , так что на самом деле он не выполняет никакой работы — он просто передает вызовы (но с протоколированием и т.д.). Среди прочего, я предоставил DbProviderFactory из своего пользовательского соединения, которое реализует IServiceProvider и предоставляет пользовательский DbProviderServices .

Это отлично работает для большинства инструментов, включая LINQ-to-SQL, однако Entity Framework не устраивает.

Например, скажем, у меня есть:

 MetadataWorkspace workspace = new MetadataWorkspace(
     new string[] { "res://*/" }, 
     new Assembly[] { Assembly.GetExecutingAssembly() });
using(var conn = /* my custom wrapped DbConnection */)
{
    var provider = DbProviderServices
          .GetProviderServices(conn); // returns my custom DbProviderServices
    var factory = DbProviderServices
          .GetProviderFactory(conn); // returns my custom DbProviderFactory
    ...
  

пока все хорошо — вышеупомянутые две строки работают; возвращается правильная (пользовательская) информация о поставщике.

Теперь мы можем добавить модель EF:

     using (var ec = new EntityConnection(workspace,conn))
    using (var model = new Entities(ec))
    {
        count = model.Users.Count(); // BOOM!
    }
  

сбой с исключением:

Не удается преобразовать объект типа ‘(мое пользовательское соединение)’ в тип ‘System.Data.SqlClient.SqlConnection’.

который выполняется во время назначения соединения команде; по сути, он по умолчанию передан поставщику sql-сервера для SSpace и сгенерировал naked SqlCommand . Затем он пытается назначить conn сгенерированной команде, которая не может работать (она будет работать правильно, если все декораторы на месте, а вместо них использовался оформленный DbCommand ).

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

Работает следующее, взламывая внутренности SSpace (установка private readonly поля, о котором у меня нет прав знать или злоупотреблять):

     StoreItemCollection itemCollection =
        (StoreItemCollection)workspace.GetItemCollection(DataSpace.SSpace);
    itemCollection.GetType().GetField("_providerFactory",
        BindingFlags.NonPublic | BindingFlags.Instance)
        .SetValue(itemCollection, factory);
  

При этом используется правильная фабрика SSpace . Однако это явно неприятно из-за неприятности.

Итак: я упускаю какой-то трюк? Как я могу перехватить поставщика EF с помощью менее радикальных мер?