c# - 我应该在我的实体框架数据访问层中存储硬编码数据吗？

我有一个使用 .NET Core EF 作为数据访问层的 3 层应用程序。当然，除此之外，我还有我的业务逻辑，它利用 EFDbcontext执行数据库 CRUD 操作。

我现在处于一种情况，我希望能够拥有国家和州的对象，即：

public class CountryAndStates
{
    public string Country { get; set; }
    public List<string> States { get; set; }
}

我决定不将这些数据放入数据库中，因此对其进行硬编码，因为这是静态数据。

我现在的问题是，我会将这些数据放在我的应用程序中的什么位置？最理想的情况是，我想以某种方式将数据放在我的数据访问层中会很好，这样我就可以通过我的DbContext实例访问它。

但是，我不确定这是否是个好主意。因此，我想知道从软件架构的角度来看，如何以最佳方式解决这个问题。

标签： c#asp.net-mvcentity-frameworkasp.net-core

我将为此投入 2 美分。您的数据访问层应该隐藏所有数据存储的实现：数据库、文件、对外部 API 的调用。

你的 BL 永远不应该直接使用 DbContext ，甚至不应该知道它的存在；因为这使您的 BL 依赖于将您的 BL 与您的 DAL 紧密耦合的实现细节......

如果您决定不再使用实体框架怎么办？

如果您想合并其他数据存储，如 json 文件或对外部 api 的调用，该怎么办？

您会看到从 BL 调用 DbContext 违背了分层架构的目的。

更不用说它违反了 SOLID 设计的几个原则。

实际上，在专业架构的软件中，您的 BL 将通过接口以松散耦合的方式与 DAL 交互。BL 不会知道数据存储的任何实现细节，也不会关心数据来自哪里。它只是从 DAL 时期回来的实体。

此外，通过直接从您的 BL 中使用 DbContext，您将数据访问与违反封装和单一职责的业务逻辑混合在一起。

如果您分离和封装您的 DAL，您可以添加任何类型的数据存储，而无需重新考虑您的业务逻辑层。