c# - 使用实体框架时，POCO 是正确的选择吗？

Question

我已经阅读了一段时间的 POCO（普通旧 CLR 对象），但仍然找不到使用它而不是使用实体框架的自动生成的部分类的真正附加值？还有一件事是最好直接从表示层使用我的实体框架还是创建 BLL 会更好？

Answer 1

POCO 的主要好处是您可以将其传递给不需要了解有关实体框架的任何信息的类、库或程序集即可完成其工作。

记住单一职责原则——你的 DAL 应该知道 EF，但你的域不应该，你的表示层也不应该，因为 EF 处理数据访问而那些层不。将 EF 生成的类对象传递到这些层通常意味着您需要让这些层了解 EF，破坏 SRP 并使孤立地对这些层进行单元测试变得更加困难。

针对阿里在下方评论中的进一步询问，这里做个扩展解释。

在更复杂的应用程序中，您将希望将逻辑拆分为单独的关注点 - 数据访问、业务逻辑、表示（可能还有更多）。

由于实体框架处理数据访问，它位于数据访问层 - 在这里，您将看到 POCO 和 EF 生成的类之间几乎没有区别。这很好，因为这一层已经知道实体框架。

但是，您可能希望将数据向上传递到业务逻辑层 - 如果您使用 EF 生成的类执行此操作，那么您的业务逻辑层还必须了解实体框架，因为 EF 类依赖于 EF 专门提供的许多东西。这样做是为了消除您的业务逻辑层应该具有的隔离 - 您需要这种隔离，以便您可以通过将已知数据从假数据访问层注入到类中来正确地对其进行单元测试，如果您让业务逻辑层了解 EF。

通过单元测试，您应该测试层功能，而不是第三方库的功能 - 但是使用 EF，您最终会测试很多 EF 的功能，或者您自己的功能，这些功能非常依赖于 EF 的功能。这不好，它可以掩盖错误或问题。

删除对 EF 生成的类的业务逻辑依赖还允许您将该层从数据访问层移动到您喜欢的任意远程位置 - 您甚至可以将其粘贴在 Web 服务后面，它会非常高兴。但是您只能使用 POCO 执行此操作，而无法使用 EF 生成的类执行此操作。

POCO 确实在大型、复杂的多层应用程序中发挥了作用——如果您不分层应用程序，那么恕我直言，您将看不到一大堆好处。

所有这些都是我的观点，我只是一个有经验的编码员 - 我不是编码摇滚明星，所以其他一些评论者可能想进一步扩展我的答案......

Answer 2

在 ORM 中使用 POCO 类允许您以更简单的方式为该代码创建测试。它还允许您在模型对象（PO​​CO 类）和数据访问代码之间有一个抽象层，因此如果需要，您可以交换数据访问代码（例如，EF 代表 NHibernate）。

我过去使用过 POCO 模型，我可以告诉您，它对于大型企业项目和大型开发团队非常有用，因为模型经常发生更改，并且 EF 默认使用的单一文件模型不能很好地扩展. 小项目或快速应用程序开发的好处很难看到。

TLDR 版本：如果您问自己 POCO 和代码优先的好处是什么，您可能不会从使用它们中获得任何好处。

Answer 3

POCO 的真正好处是您可以使用代码优先和 EF 迁移。如果您不打算首先使用代码，则可以使用设计器生成的类。

如果您有一个大型应用程序，您应该创建一个单独的 BLL，但如果您的应用程序非常小，您可能可以直接使用表示层中的 EF 类。