我们有一个 ASP.Net MVC2 网站，并且正在使用 EF4 进行数据库访问等。作为 EF4 的新手，我们遇到了 EF4 POCO 概念，但并不完全理解它。
一般来说，我听说 POCO 被定义为“不依赖于外部框架”的对象。在 EF4 的情况下，我猜这意味着 POCO 会暗示以某种方式创建更轻量级的实体？如果是这种情况，POCO 没有什么 EF4 管道，这样做的优点/缺点是什么，POCO 可能需要哪些额外的开发工作。综上，EF4什么时候用POCO比较好？
【问题讨论】：
标签： entity-framework oop entity-framework-4 poco
“POCO”在 ORM 空间中是一个模糊的术语。人们用它来表示：
public virtual 并且在运行时具有不同类型。EntityObject。我发现“不依赖于外部框架”的定义有点自私。这是一种忽略框架限制的方法。即，在我的书中，代理不是真正的 POCO，但它们符合该定义。
EntityObject 有什么问题？不是很多。它相当轻巧，并且是 .NET 的一部分。它甚至在 .NET 4 客户端配置文件中。它甚至不会将您链接到 EF。尽管将它用作具有不同框架的“POCO 类型”会有点奇怪，但它会工作得很好。不过，它不在 Silverlight 中，IIRC。
POCO 实体更难使用，因为您丢失了 EntityObject 免费提供的东西。这不是很多，但在选择 POCO 之前需要考虑一些事情，因为“它们很酷”，尤其是对于那些刚接触 EF 的人。
很多热衷于 POCO 的人往往会忽略一件事：映射非 POCO 类型绝不会限制您在外部公开这些非 POCO 类型。您的数据服务可以将映射的非 POCO 类型投影到未映射的 POCO DTO 上，您可以选择仅公开这些类型，即：
public IEnumerable<FooDto> IFooRepository.SelectAll()
{
return from f in Context.Foos
select new FooDto { Id = f.Id, Name = f.Name };
}
因此，如果您愿意，映射类型和数据服务类型很容易成为不同的关注点。
什么时候你绝对需要非EntityObject 类型的映射？好吧，如果您需要自我跟踪实体，那么这是一个开放和封闭的案例。如果您必须将映射类型公开给 Silverlight，那么显然也是如此。
除此之外还不太清楚。如果您正在编写供公众使用的数据服务，那么您不应该将 DTO 设为 EntityObject 子类型，因为这会妨碍以后插入不同的框架。 我永远不会创建一个依赖于任何一个框架的不可变的公共接口，即使是 .NET 中包含的一个。 另一方面，正如我上面所说，您可以公开一种类型并映射另一种类型；从来没有要求公开映射类型，而且通常有很好的理由不公开它们（也许它们包含非公共数据）。
【讨论】：
我完全同意 Craig 的观点，POCO 更难处理。
我会补充更多关于 POCO 的用途，希望你能明白什么时候该使用它，什么时候不该使用它。
模型和服务是核心
模型和服务是你的应用程序中最重要的部分之一，改变是不可以的，你不能避免将模型和服务与应用程序的任何部分紧密耦合，因此模型的变化很小需要更改整个应用程序。
这关乎灵活性
POCO 是特定于语言的问题，而不是特定于框架的问题。它是一个简单的类，与框架特定的类没有依赖关系，您可以在所有 .net 版本中使用 POCO，包括微框架和紧凑框架。
这是关于测试的
POCO 非常容易进行单元测试，因为它不依赖于非单元测试友好的类。
这是关于变化
升级/降级，在 MONO 等不同环境下制作新的客户端应用程序？没问题，您可以继续使用您的服务和模型，即使最糟糕的升级/降级也只会发生在 View and Service Cotext Helper 上。
这是关于自然的
创建和使用 POCO 简单自然，您可以清楚地编写业务流程。
但请记住 POCO 对框架不友好
我同意 Craig 的观点，POCO 太酷了，太酷了，无法结交新朋友。看看 WPF 它需要一个实现 INotifyPropertyChanged 的模型，你做了什么来实现它？您可以制作包装器，也可以制作模型的动态代理。但这需要更先进的技术和代码来维护。
【讨论】：