我在过去五个月里一直在开发一个应用程序，并且遇到了这个问题。
我们正在使用EF5，与this question类似，我设计了类层次结构，以使所有实体类派生自抽象基类，以强制实现验证接口。我们还在实体类中使用验证属性。
在我开始尝试在WCF服务中使用实体类之前，一切都运行良好。我得到了一堆序列化异常，并一直试图找出我在设计中破坏的“POCO”规则。 This article告诉我课程（显然......）不能是抽象的，但由于我的课程是从抽象课程中衍生出来的，我是否违反了一条我不知道的规则？
更新：以下是我正在努力的例外：
System.Runtime.Serialization.SerializationException，mscorlib，Version = 4.0.0.0，Culture = neutral，PublicKeyToken = b77a5c561934e089
输入数据合约名称为“WorkSession_63308485A9007DE087FF55AD9F246FD677863AA39AD56FEF4586AB87E21832DD：http://schemas.datacontract.org/2004/07/System.Data.Entity.DynamicProxies”的'System.Data.Entity.DynamicProxies.WorkSession_63308485A9007DE087FF55AD9F246FD677863AA39AD56FEF4586AB87E21832DD'。考虑使用DataContractResolver或将任何静态未知的类型添加到已知类型列表中 - 例如，使用KnownTypeAttribute属性或将它们添加到传递给DataContractSerializer的已知类型列表中。
答案 0 :(得分：2)
由于您的POCO使用延迟加载，因此您不会从EF获取实际类型，而是获取代理，以便为延迟加载自动实现导航属性。
我的建议是忘记从Web服务公开域对象的想法。我打赌会有答案试图说服你，在这个特殊的情况下这是可能的，有一堆额外的法术。但是，最安全的方法是将您的想法转换为 DTO ，数据传输对象，这是一种模式，您可以在其中创建一个额外的“仅数据”类层，这些类很轻，可以安全地序列化并通过丝。
有许多很棒的文章解释了如何使用DTO模式和一些额外的支持技术（如AutoMapper）公开您的数据。您可以轻松找到详细信息，然后您可以回来寻求进一步的答案。
答案 1 :(得分：1)
你没有打破“POCO规则”。异常中提到的“动态代理”是一个来自WorkSession实体的派生的类，但它不是在您的代码中派生的，而是在运行时动态生成的。如果您已将导航属性（也可能是标量属性）标记为virtual，则实体框架会执行此操作（默认情况下）以使延迟加载和动态更改跟踪成为可能。
当您打算使用WCF序列化实体时，应禁用动态代理创建。您可以通过在上设置标志来从数据库加载实体之前设置一个标志：
context.Configuration.ProxyCreationEnabled = false;
var worksessions = context.WorkSessions.....ToList();
加载的worksessions现在是真正的运行时类型WorkSession，而不是动态代理类型，WCF不应该再抱怨了。