从存储库而不是 EF 实体返回 POCO 对象的优点/缺点是什么？答案

【问题标题】：What are the pros/cons of returning POCO objects from a Repository rathen than EF Entities?从存储库而不是 EF 实体返回 POCO 对象的优点/缺点是什么？
【发布时间】：2009-05-11 08:52:58
【问题描述】：

按照 Rob 的做法，我拥有由 Linq to SQL 向导生成的类，然后是那些作为 POCO 的类的副本。在我的存储库中，我返回这些 POCO 而不是 Linq to SQL 模型：

从 DataContext.Customer 中的 c 返回其中 c.ID == id 选择新的 MyPocoModels.Customer { ID = c.ID, Name = c.Name }

我知道这样做的好处是 POCO 模型可以更容易地实例化，因此这将使我的代码更具可测试性。

我现在正在从 Linq 迁移到 SQL 再到 Entity Framework，而且我已经读完了一本 EF 书。通过从我的存储库而不是 EF 实体返回 POCO，我似乎会失去很多好处。

我还没有真正接受单元测试，所以我觉得我浪费了很多时间来创建这些额外的 POCO 并编写代码来填充它们，而我似乎获得的只是可测试的代码，但我由于无法跟踪我的对象，也会失去 EF 的许多好处。

对于所有这些 ORM/Repository 东西的相对新手有什么建议吗？

安东尼

【问题讨论】：

刚刚意识到我错过了帖子的第一行，我想说的是我一直在关注 Rob Conery 的 Storefront 系列，并开始在我的小项目中使用他的存储库模式。跨度>

标签： entity-framework orm repository-pattern

【解决方案1】：

人们不喜欢自动生成的对象（例如在 LINQ to SQL 中）的另一个原因是它们内置的“魔法”。

通常魔法是不可见的，你永远不会注意到它，但是当你尝试序列化其中一个对象然后反序列化它（例如在使用 Web 服务时）时，它与数据源的内部连接会中断并且是特殊的需要使用技巧来“恢复魔法”。

使用 POCO，您不必担心这些事情，并且可以更好地分离数据和服务层。缺点当然是你必须写很多无聊的 POCO -> 魔术对象和魔术对象 -> POCO 转换代码。但最后我认为这通常是值得的，尤其是对于大型或复杂的项目。

【讨论】：

【解决方案2】：

主要原因是很多人喜欢以特定的思维方式开发他们的模型：例如 DDD。他们可能希望对状态（而不是枚举）等事物使用特定模式（如 Spec 或 State） - 或者您可能希望使用 Factory 进行实例化。

当事情变得更复杂时，当您尝试将表用作对象时，OO 会中断。简单的网站可以正常工作 - 但是当您处理大事时，它会变得很丑。

所以 - 一如既往 - 这取决于您认为您的项目会变成什么。

【讨论】：

【解决方案3】：

我的经验是，当您开始编写一些复杂的查询时，.Include 方法毫无价值，您会发现自己：

a) 编写大量查询以获取您想要的数据或 b) 滥用匿名类型在单个查询中加载数据，然后编写大量代码只是为了将该数据传递给您的实体。

POCO 是要走的路，恕我直言。

【讨论】：