在数据访问和业务逻辑层分开的情况下，可以在业务层使用Entity框架类吗？我可以在单独的数据访问和业务逻辑层中使用业务层中的实体框架类吗？编辑：我不认为将来我需要从我的业务逻辑中换出数据访问层（即将成为SQLServer），但我会换成UI层。所以问题更多的是在业务层为我使用EF类是否存在任何重大问题？似乎管道代码会更少。一般来说，“最佳实践”方法是这样的：好处是您的业务层域模型代表您正在使用的实际业务对象，并且或多或少独立于这些对象在数据层中的实际存储方式。此外，这避免了将UI层“粘合”到特定的数据访问技术。当然——这是推荐的企业级应用的最佳实践，你可能需要更换数据访问层等。对于更简单的应用，你可以跳过动手，了解你在做什么，你是谁？如果您一直使用EF实体通过业务层进入UI，请将自己“锁定”在EF中。如果您和您的应用程序都很好-没有特别的理由不这样做。EF实体是完全有效的.NET对象类——它们只是从一个公共基类（EntityObject而不是对象）派生而来，并且它们有一定数量的“包袱”。但没有什么能阻止您在整个应用程序中使用这些EF实体。与所有此类性质的问题一样，答案取决于它。如果您想要将数据访问逻辑和业务层完全分离，我会说不。如果那是你的目标，我会使用存储库模式和IoC来构建数据访问层，然后你可以换出存根DAL进行单元测试，然后在进行功能测试时引入数据库访问。如果您需要能够在不重写大量代码的情况下改变访问数据库的方式，最好将EF置于业务层之外。您可以使用工作单元和存储库模式来实现这一点；数据层的所有功能都通过接口访问。如果去掉EF，接口保持不变，只是改变了实现类。但是，有不使用UoW和存储库的参数，主要是DbContext已经为您提供了许多这些功能。我开始了一个项目，在数据层中使用UoI和存储库，在业务层中没有EF引用。随着我的进步，我觉得我只是在为自己工作，然后就放弃了。相反，我使用业务层的访问上下文，执行从DTO到业务层POCO所需的任何转换。在我的场景中，我有信心坚持使用EF。如果没有，请考虑适合您的方法。以上是C#学习教程：在单独的数据访问和业务逻辑层，是否可以在业务层使用Entity框架类？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
