使用EF处理的IOptions<T>设计类？
使用EF处理的IOptions<T>设计类？
提问于 2021-09-13 23:00:20
我有一个类包含一些我存储在数据库中的信息。
class SomeThing
{
public Guid Id { get; set; }
public string Name { get; set; }
public string Info => "extra info";
}当然，entity.Ignore(a => a.Info);的EF省略了最后一个属性。现在，我希望文本额外的信息可以从appsettings.json中设置，所以我引入了一个选项提供程序，并使用构造函数(在Startup.cs中注册它之后)注入它。DI要求我使用一个参数化的构造函数，而EF则需要一个无参数的构造函数，因此我的类变得有点阻塞。
class SomeThing
{
private IOptions<Config> Config { get; }
public SomeThing() { }
public SomeThing(IOptions<Config> config)
{
Config = config;
}
public Guid Id { get; set; }
public string Name { get; set; }
public string Info => Config.Value.Info;
}现在，笨重的复杂性让我怀疑我的设计有缺陷。另外，我不认为EF应该如何注入选项的值，因为它依赖于无参数的构造函数。我考虑过实现空构造函数并以某种方式获取服务，手动获取值，但在我看来，这是一个巨大的危险标志。
我应该如何对待这类课程的设计？
回答 2
Stack Overflow用户
回答已采纳
发布于 2021-09-14 04:41:43
不管这是一个有问题的设计决策，您都应该将这项工作委托给存储库类。
ThingRepo.GetSomeThing()获取实体并在需要时填充Info属性。然后，它可以在构造函数中注入IOptions<T>。
class ThingRepo
{
private Config _config;
private DbContext _db;
public ThingRepo(IOptions<Config> config, DbContext db)
{
_db = db;
_config = config.Value;
}
public async Task<Thing> GetSomeThing()
{
var thing = await _db.Set<Thing>().FirstAsync();
thing.Info = _config.Info;
return thing;
}
}这避免了必须在实体构造函数中要求IOptions<T>的限制。
Stack Overflow用户
发布于 2021-09-14 01:08:37
由于SomeThing是数据库的实体定义，所以我避免使用DI向其中注入选项。我不认为这是一个支持的方案在EF核心无论如何。
如果您确实需要访问Info对象，您可以引用另一个与DI兼容的服务，但同样，直接从调用代码访问从SomeThing访问Info不会更容易吗？
通常，EF核心用于将数据存储在数据库中。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/69173191
复制
相似问题
Roslyn是否支持项目/编译级诊断的代码修复操作(没有位置)？
无法创建新的“诊断与代码修复”项目！(Roslyn+VS2013)
Resharper支持Roslyn诊断和快速操作的代码修复
非文本的Roslyn代码诊断报告？
Roslyn诊断注册
添加站长 进交流群
领取专属 10元无门槛券
AI混元助手 在线答疑
关注 腾讯云开发者公众号
洞察 腾讯核心技术
剖析业界实践案例
腾讯云开发者
