我想将自定义连接字符串注入到我的 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
,但这似乎也很臭。我不知道为什么,但我的大脑说坏主意。
经过一番调查,我发现,可以通过编辑 T4 模板来告诉 EF 包含这个额外的构造函数,该模板Model.Context.tt
是 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
?如果是这样,我该怎么做?