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

Question

我有一个 3 层应用程序，它利用 .NET Core EF 作为数据访问层。 当然，最重要的是我有我的业务逻辑，它利用 EF Dbcontext来执行数据库 CRUD 操作。

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

这取决于您如何使用这些静态数据。

但我的偏好是始终保持 DBContext 准确反映您的数据库，因此它是单一责任。 因此，它更容易维护。

然后我会将这些静态数据放在逻辑层的“utils”文件夹中。 或者甚至把它放在一个“utils”项目中，如果你的业务层中有很多项目。

Answer 3

Alex - Tin Le 是正确的，但这是科学原因。

从制造的角度来看，流程应该与您的物料清单 (BOM) 分开。 制造订单包含选择现有组件的过程和行为。

因此，在处理用户操作之前，您的控制器操作 - 您的订单 - 消耗此数据应该引用实例化的水合 CountryAndStates 模型。 数据库绝对不是外部数据的字典文件，外部数据可能来自文件甚至google web API调用。 将这些类存储在与数据库模型不同的文件夹和命名空间中，因此如果需要，每个组件类都可以包含自己的加载器。 自然地，您应该使用基类标准化组件，以便您的控制器可以处理加载失败。

Answer 4

我建议的是所谓的“服务器端缓存”，这是处理静态数据的常见做法。

您可以创建一个static Dictionary<string,List<string>>并在应用程序启动时通过从数据库或任何其他资源中读取数据来初始化此字典（您甚至可以按照您提到的方式对数据进行硬编码）。

然后你可以考虑并把这个字典当作一个datasource并在你的数据访问层添加函数来访问字典。

这种方法的明显好处是提高了性能。

Answer 5

您可以将数据存储在应用程序层的资源文件中https://docs.microsoft.com/en-us/dotnet/framework/resources/creating-resource-files-for-desktop-apps

或者您可以重新考虑并为数据创建一个 DB 对象，并将其缓存在应用程序层