我对IoC，依赖注入和单元测试都很陌生。我正在开始一个新的宠物项目，我正在努力做到这一点。
我打算使用Repository模式来调解数据。我将从存储库返回的对象将是从 Linq收集到实体数据上下文（EF4）的对象。
我正在阅读Mark Seeman的“依赖注入”，认为这样做会产生一个重要的依赖性，并且肯定会使测试变得复杂（这就是他在图书馆计划中使用POCO对象的原因）。
我不明白为什么。虽然对象是由linq到实体上下文创建的，但我可以创建它们只是调用构造函数，因为它们是普通对象。所以我认为可以创建伪造的存储库，将这些对象转发给调用者。
我也很关心自动生成POCO类，这并不容易。
有人可以带点光吗？ POCO对象是解耦和可测试项目的必要条件吗？
* *编辑：感谢Yuck我明白最好避免使用模板自动生成，这让我想到了一个设计问题。如果我来自一个庞大的遗留数据库，他的表格承担了各种责任（不适合具有单一责任的类的概念），那么处理这个问题的最佳方法是什么？
删除数据库不是一个选项; - ）
答案 0 :(得分：3)
不，他们没有必要，只是让事情变得更容易，更清洁。
POCO库不会知道Entity Framework正在使用它。这允许以其他方式使用它 - 例如代替视图模型。它还允许您在WCF服务的两侧使用相同的项目，从而无需创建数据传输对象（DTO）。
仅举两个个人经验的例子，但肯定会有更多。一般来说， less 特定对象或代码片段知道谁正在使用它或如何使用它将使更多适应性和通用性适用于其他情况。
您还提到自动生成POCO类。我不建议这样做。您是否计划从数据库结构生成类定义？
答案 1 :(得分：2)
我打算使用Repository模式来调解数据。 我将从存储库返回的对象是 将是从Linq收集到实体数据上下文的对象 （EF4）。
EF生成的默认类（不是POCO）包含延迟加载的代理，并且与实体框架紧密相关。这意味着任何其他想要使用这些类的类都必须引用所需的EF程序集。
这是Mark Seeman所说的依赖。由于您现在依赖于这些非抽象类型，而这些类型又依赖于EF，因此您无法简单地将存储库的实现更改为不同的（即仅使用您自己的持久性存储），而无需在依赖于此类的类中解决此更改关于这些类型。
如果您真的只对EF生成的类型的公共属性感兴趣，那么您可以让EF生成的部分类实现基本接口。将所需的所有属性放在该基本接口中，并将依赖项作为基接口传递 - 现在您只依赖于基本接口而不再依赖于EF。