您的代码优先类是您的域类吗？ [关闭]

Question

我什至不确定我是否能正确地表达这一点，但是......

我开始使用代码优先的实体框架来构建解决方案，并且开始感觉到我正在用太多特定于 DB 的信息污染我的域类（EF 将用来生成 DB 的类）：我必须使某些方法虚拟化才能发生延迟加载，我正在将明确针对数据库配置的属性添加到我的属性中，等等。我还担心这些课程在整个项目中的普及程度。

首先，我是否有道理和/或我是否从根本上误解了应该如何使用 EF？

其次，如果我理解这一点，我的问题是：是否有其他人区分用于生成数据库的代码优先类和域类（可能使用自动映射器从其他）？

Answer 1

我花了很长时间尝试不同的方法来解决这个问题。在其简单性方面，使用 Entity Framework 也可以非常容易地将数据类用作域类。

我的经验是，在小型项目中，您可以不使用 EF 类作为域类。这是快速和简单的，但是随着项目变得越来越大，这开始成为问题，因为您无法以任何方式控制访问。

最常见的情况是在 EF 类上公开导航属性。您的整个应用程序现在将能够导航您的整个数据集。因此，使用此模型，您将放弃对数据和域对象的所有控制。

将域类与 EF 分开有几个优点。首先，您不会与 EF 或代码优先那么紧密相关。通过一定程度的分离/间接，您将能够根据需要更换您的数据框架。其次，您能够更有效地控制您的数据。

就我个人而言，我已经达到了一个务实的点，我在每个项目开始时都会做出这个决定。如果项目很小且包含，那么我可能会避免这种额外的抽象以支持简单性。在几乎所有的中型和/或大型项目中，我都有分离。

Answer 2

如果您要在编码中使用 SOLID 原则，您确实应该将数据实现（在您的情况下首先是 EF 代码）与域/业务逻辑分开。映射它们有点开销，但考虑一下当您需要从 Web 服务访问某些数据时会发生什么？

此外，您的域类通常包含计算或派生的值（例如全名、地址），这些值不会出现在您的数据库类中，反之亦然（例如数据库日志信息）

我首先会搜索存储库模式。