从存储库中返回POCO对象与EF实体相比有什么优缺点？

Question

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

return from c in DataContext.Customer
       where c.ID == id
       select new MyPocoModels.Customer { ID = c.ID, Name = c.Name }

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

我现在正从Linq迁移到SQL，再到实体框架，我大约只有EF书的一半。通过从我的存储库而不是EF实体返回POCO，我似乎会失去很多好处。

我还没有真正接受过单元测试，所以我觉得我浪费了很多时间来创建这些额外的POCO并编写代码来填充它们，当我看起来正在获得的是可测试的代码时，我由于无法跟踪我的物体，因此也会失去EF的许多好处。

有没有人对所有这些ORM / Repository的相关内容有任何建议？

安东尼

Answer 1

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

通常魔法是不可见的，你从来没有注意到它，但是当你尝试做一些事情，比如序列化其中一个对象然后反序列化它（例如当使用Web服务时）它与数据源的内部连接被打破并且特殊黑客需要被用来“把魔法放回去”。

使用POCO，您不必担心这些问题，可以更好地分离数据和服务层。当然，缺点是你必须写很多无聊的POCO - ＆gt;魔法物体和魔法物品 - ＆gt; POCO转换代码。但最后我认为这通常是值得的，特别是对于大型或复杂的项目。

Answer 2

主要原因是很多人喜欢用特定的心态开发他们的模型：比如DDD。他们可能希望使用特定模式（如Spec或State）来处理状态（而不是枚举） - 或者您可能希望使用Factory进行实例化。

当事情变得更复杂时，尝试将Tables用作对象时，OO会中断。简单的网站工作正常 - 但是当你做大事时，它会变得丑陋。

所以 - 一如既往 - 这取决于您对项目的看法。

Answer 3

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

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

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