8

按照 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 东西的相对新手有任何建议？

安东尼

4

3 回答 3

6

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

通常魔法是不可见的，你永远不会注意到它，但是当你尝试序列化其中一个对象然后反序列化它（例如使用 Web 服务时）时，它与数据源的内部连接被破坏，需要特殊的黑客攻击被用来“把魔法放回去”。

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

于 2009-05-13T19:44:37.980 回答
4

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

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

所以——和往常一样——这取决于你认为你的项目会变成什么。

于 2009-05-13T18:50:02.017 回答
2

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

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

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

于 2009-05-13T19:35:17.123 回答