您的代码优先类是您的域类吗？

Question

我不确定我是否能恰当地表达这一点，但......

我开始使用代码优先实体框架构建一个解决方案，并开始感觉我正在污染我的域类（EF将用于生成数据库的类）具有太多特定于数据库的信息：我必须使某些方法是虚拟的，以便可以进行延迟加载，我将明确针对数据库配置的属性添加到我的属性中，依此类推。我也担心这些课程在整个项目中会有多普遍。

首先，我是否有意义和/或我是否从根本上误解了如何使用EF？

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

Answer 1

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

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

我在第一个实例中搜索存储库模式。

Answer 2

我花了很长时间尝试不同的方法解决这个问题。简单起见，Entity Framework也可以非常轻松地将数据类用作域类。

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

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

将您的域类与EF分开有几个好处。首先，你不会像EF或代码优先那样严格依赖。通过一定程度的分离/间接，您可以根据需要更换数据框架。其次，您可以更有效地控制数据。

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