将自定义连接字符串注入Entity Framework的DbContext

Question

我想在我的EF上下文中注入一个自定义连接字符串,而不是在我的web.config中使用连接字符串.我们的想法是将所有与数据库相关的逻辑从我的MVC项目移到一个单独的层.我还希望这个层负责正确的连接字符串而不是我的Web应用程序.

当前使用上下文的服务正在调用默认构造函数:

using (var context = new MyDbContext()) {
    //...
}

默认构造函数在内部DbContext使用以下连接字符串的名称进行调用web.config:

public partial class MyDbContext : DbContext
{
    public MyDbContext()
        : base("name=MyDbContext")
    {
    }

    //...
}

为了注入我的自定义连接字符串,我需要一个重载的构造函数,它将连接字符串作为参数.不幸的是,没有提供这样的构造函数.

很明显,在MyDbContext类中手动添加构造函数重载将是一个非常糟糕的主意,因为这个类是自动生成的,并且很快就会被覆盖.我们不再谈论这个,这是禁止的.期.

由于MyDbContext是一个部分类,可以在一个单独的类文件中添加额外的构造函数partial class MyDbContext,但这看起来也很臭.我不知道为什么,但我的大脑说不好主意.

经过一些调查后我发现,通过编辑T Model.Context.tt#模板,可以告诉EF包含这个额外的构造函数,这是C#和一些模板标记的混合.这是原始构造函数:

public <#=Code.Escape(container)#>()
    : base("name=<#=container.Name#>")
{
<#
    WriteLazyLoadingEnabled(container);
#>
}

显然很容易添加类似的逻辑来生成包含连接字符串的重载构造函数:

public <#=Code.Escape(container)#>(string nameOrConnectionString)
    : base(nameOrConnectionString)
{
<#
    WriteLazyLoadingEnabled(container);
#>
}

我试过这个并注意到,重新生成模型类和从DB更新模型都不会影响T4模板,因此额外的构造函数将始终存在.好!乍一看,这看起来是一个合适的解决方案,但......

这是我的问题:这真的是一个很好的解决方案吗？

让我们再次比较三个选项:

1. 编辑自动生成的类(好吧,我们同意忘了这个)
2. 在部分类文件中添加构造函数
3. 编辑T4模板以告知EF生成其他构造函数

从这三个选项中,第三个似乎是我最方便,最干净的解决方案.你有什么意见？有人有充分的理由,为什么这会是一个坏主意？是否有更多选项来注入连接字符串,可能使用自定义connectionFactory？如果是这样,我该怎么做？

Answer 1

从您提供的 3 个选项中，我宁愿选择选项 2。难道没有引入partial 关键字来解决自动生成文件的问题吗？在我看来，使用 T4 模板会带来额外的复杂性，维护开发人员必须了解一件事（不是每个人都熟悉 T4），但扩展部分类是更标准的 C# 开发。

然而我不知道“是否有一个真正好的解决方案”的答案。引入工厂再次带来新的代码来维护、测试和理解，我不确定这种抽象在这里有帮助，因为工厂本身需要实例化dbcontext 具有适当的构造函数（无论如何您都必须提供）。

编辑：

再想一想：工厂可能有助于从另一个位置解析连接字符串（您说您不希望 web.config 中的连接字符串），但这仍然不能解决构造函数问题