c# - 在单独的数据访问和业务逻辑层中，我可以在业务层中使用 Entity Framework 类吗？

Question

在单独的数据访问和业务逻辑层，我可以在业务层使用 Entity Framework 类吗？

编辑:我认为我将来不需要从我的业务逻辑中换出数据访问层(即，将是 SQL Server)，但我会换成 UI 层。因此，问题更像是在业务层为我使用 EF 类时是否存在任何重大问题？似乎管道代码会更少。

Answer 1

通常，“最佳实践”方法是这样的:

• 在您的数据层中，您拥有从数据库加载并存储回数据库的 EF 实体

• 在您的业务层中，您拥有自己的域对象(只是简单的 C# 类)，它们表示您的应用需要处理的数据。这些可以或多或少与数据层实体相同，或者它们可以包含几个“原子”实体来构成一个业务对象，或者它们可以有很大的不同。为了减少对大量左手右手赋值语句的需要(在数据层实体和业务层对象之间来回移动属性值)，您应该查看像 AutoMapper 这样的工具。这使得在相似对象类型之间设置“映射”变得非常容易，并允许您轻松地来回分配这些类型

• 然后，您的 UI 层将可视化并向用户表示业务层对象以供信息和/或操作

好处是您的业务层域模型代表您正在使用的实际业务对象，并且或多或少地独立于这些对象在数据层中的实际存储方式。此外，这可以避免将您的 UI 层“粘合”到特定的数据访问技术。

当然 - 这是推荐的企业级应用的最佳实践，您可能需要在其中交换数据访问层等。对于更简单的应用，您可以跳过这些实践，知道你在做什么，如果你一直使用 EF 实体通过业务层进入 UI，你就是在将自己“锁定”到 EF 中。如果这对您和您的应用程序场景没问题 - 没有特别的理由不这样做。 EF 实体是完全有效的 .NET 对象类 - 它们只是从公共(public)基类(EntityObject 而不是 object)派生而来，并且它们有一定数量的“包袱”沿着。但没有什么能阻止您在整个应用程序中使用这些 EF 实体。