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模板，因此额外的构造函数将始终在那里。好！乍一看，这看起来是一个合适的解决方案，但是......

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

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

编辑自动生成的类（好的，我们同意忘记这个）
在部分类文件中添加构造函数
编辑T4模板以告知EF生成其他构造函数

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

Answer 1

与@shaft proposed一样，我将T4模板方法替换为使用分部类。事实证明，这确实比我目前所知的任何其他解决方案更简单直观。

自动生成的类看起来像：

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

    //...
}

我刚添加了另一个同名的部分类。问题解决了。

public partial class MyDbContext 
{
    public MyDbContext(string nameOrConnectionString)
             : base(nameOrConnectionString) 
    {
    }
}

Answer 2

从您提供的3个选项中，我宁愿选择选项2.是否已引入partial关键字来解决自动生成文件的问题？在我看来，使用T4模板带来了额外的复杂性，维护开发人员不仅要了解一件事（不是每个人都熟悉T4），而扩展部分类是更标准的c＃开发。

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

编辑：

再次考虑一下：工厂可能对从另一个位置解析连接字符串很有用（你说你不想在web.config中使用连接字符串），但仍然无法解决构造函数问题

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

2 个答案: