EF实体为什么要建立依赖关系以及POCO的需求
本文关键字：POCO 需求 关系 依赖 实体 为什么 建立 EF | 更新日期: 2023-09-27 18:21:35
我对IoC、依赖注入和单元测试很陌生。我正在开始一个新的宠物项目，我正在努力把它做好。
我计划使用Repository模式对数据进行中介。我将从存储库返回的对象将是从Linq-to-entities数据上下文（EF4）收集的对象。
我在Mark Seeman的"依赖项注入"中读到，这样做会产生一个重要的依赖项，并且肯定会使测试复杂化（这就是他在库项目中使用POCO对象的原因）。
我不明白为什么。尽管这些对象是由linq-to-entities上下文创建的，但我可以像创建普通对象一样简单地调用构造函数来创建它们。所以我认为可以创建伪造的存储库，将这些对象传递给调用者。
我还关心POCO类的自动生成，这不是很容易。
有人能带点光吗？POCO对象对于一个解耦且可测试的项目来说确实是必要的吗？
**编辑：多亏了Yuck，我明白最好避免使用模板自动生成，这让我想到了一个设计问题。如果我来自一个大型的遗留数据库，他的表假设了各种责任（不太符合具有单个责任的类的概念），那么最好的方法是什么
删除数据库不是一个选项；-）
不，它们不是必要的，只是让事情变得更容易、更干净。
POCO库不会知道实体框架正在使用它。这允许它以其他方式使用——例如，代替视图模型。它还允许您在WCF服务的两侧使用相同的项目，从而无需创建数据传输对象（DTO）。
只有两个来自个人经历的例子，但肯定还有更多。一般来说，一个特定的对象或代码知道谁在使用它或它是如何使用的，这将使它在其他情况下更具适应性和通用性。
您还提到POCO类的自动生成。我不建议这样做。您是否计划从数据库结构中生成类定义？
我计划使用Repository模式对数据进行中介。我要从存储库返回的对象是将是从Linq到实体数据上下文中收集的对象（参考文献4）。
EF生成的默认类（而不是POCO）包含用于延迟加载的代理，并与实体框架紧密相连。这意味着任何其他想要使用这些类的类都必须引用所需的EF程序集。
这就是Mark Seeman所说的依赖性。由于您现在依赖于这些非抽象类型，而这些类型又依赖于EF，因此如果不解决依赖于这些类型的类中的这种更改，您就不能简单地将存储库的实现更改为其他类型（即，仅使用您自己的持久性存储）。
如果您真正只对EF生成的类型的公共属性感兴趣，那么您可以让EF生成的分部类实现一个基本接口。将您需要的所有属性放在该基本接口中，并将依赖项作为基本接口传入-现在您只依赖于基本接口，而不再依赖EF。