使用 EF 处理的 IOptions 设计类<T>？

Question

我有一个类，其中包含一些存储在数据库中的信息。

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应该如何注入选项的值，因为它依赖于无参数构造函数。我考虑过实现空构造函数并以某种方式获取服务，手动获取值，但在我看来，这是一个巨大的危险信号。

我应该如何设计这样一个类？

Answer 1

不管这是一个有问题的设计决策，您都应该将这项工作委托给一个存储库类。

如果需要，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>的限制。

Answer 2

由于SomeThing是数据库的实体定义，我会避免尝试使用DI向中注入选项。无论如何，我不认为这是EF Core支持的场景。

如果你真的需要访问Info对象，你可以引用一个与DI兼容的不同服务，但从SomeThing访问Info的代码中直接访问它不是更容易吗

EF核心通常用于将数据存储在数据库中。