在单独的数据访问和业务逻辑层中，我可以在业务层中使用Entity框架类吗？
在单独的数据访问和业务逻辑层中，我可以在业务层中使用Entity框架类吗？
编辑：我认为将来我不需要从我的业务逻辑中换出数据访问层（即将是SQL Server），但是我将用于UI层。 因此，问题更多的是在业务层中为我使用EF类有什么主要问题吗？ 好像管道代码会少一些。
通常，“最佳实践”方法是这样的：
-
在数据层中，您有从实体加载并存储回数据库的EF实体
-
在您的业务层中，您有自己的域对象（只是简单的C＃类），它们代表您的应用需要处理的数据。 那些可以或多或少地与数据层实体相同，或者它们可以包含几个“primefaces”实体来构成业务对象，或者它们可以是非常不同的。 为了减少对许多左手右手赋值语句的需要（在数据层实体和业务层对象之间来回移动属性值），你应该检查一下像AutoMapper这样的工具，它们很容易设置类似对象类型之间的“映射”，允许您轻松地来回分配这些类型
-
然后，您的UI层将可视化并向用户表示业务层对象以获取信息和/或操作
好处是您的业务层域模型代表您正在使用的实际业务对象，并且或多或少地独立于这些对象实际存储在数据层中的方式。 此外，这可以避免将UI层“粘合”到特定的数据访问技术。
当然 – 这是企业级应用程序的推荐最佳实践，您可能需要更换数据访问层等。对于更简单的应用程序，您可以跳过这些实践， 了解您正在做什么，以及您是谁？如果您通过业务层将EF实体一直使用到UI中，请将自己“锁定”到EF中。 如果您和您的应用场景都没问题 – 没有特别的理由不去做。 EF实体是完全有效的.NET对象类 – 它们只是从公共基类（ EntityObject而不是object ）派生而来，并且它们具有一定数量的“包袱”。 但是没有什么可以阻止你在整个应用程序中使用这些EF实体。
与所有这种性质的问题一样，答案取决于它。 如果您希望清楚地分离您的数据访问逻辑和业务层，我会说不。 如果这是您的目标，我将使用存储库模式和IoC来构建数据访问层，那么您可以交换存根DAL进行unit testing，然后在进行function测试时引入数据库访问。
如果您需要能够更改访问数据库的方式而无需重写大量代码，则最好将EF保留在业务层之外。 您可以使用工作单元和存储库模式来实现此目的; 通过接口访问数据层的所有function。 如果删除EF，接口保持不变，只需更改实现类即可。
但是，有不使用UoW和存储库的参数，主要的是DbContext已经为您提供了许多这些function。
我在数据层启动了一个带有UoI和存储库的项目，在业务层没有EF引用。 随着我的进步，我觉得我只是为自己做工，然后放弃了。 相反，我使用从业务层访问上下文，执行从DTO到业务层POCO所需的任何转换。
在我的场景中，我有信心坚持使用EF。 如果不是，请考虑适合您的方法。