未发现的 POCO 类要求
本文关键字：POCO 未发现 | 更新日期: 2023-09-27 18:33:01
在过去的五个月里，我一直在开发一个应用程序，只是遇到了这个问题。
我们正在使用 EF5，与此问题类似，我将类层次结构设计为具有从抽象基类派生的所有实体类，以强制实现验证接口。 我们还在实体类中使用验证属性。
在我开始尝试使用 WCF 服务中的实体类之前，一切正常。 我收到了一堆序列化异常，并且一直在试图弄清楚我在设计中违反了什么"POCO"规则。 这篇文章告诉我这个类(显然......(不能是抽象的，但是由于我的类是从抽象类派生的，我是否可能违反了我不知道的规则？
更新：这是我正在努力解决的例外情况：
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 的已知类型列表中。
由于 POCO 使用延迟加载，因此不会从 EF 获取实际类型，而是从代理获取，以便为延迟加载自动实现导航属性。
我的建议是忘记从 Web 服务公开域对象的想法。我敢打赌，会有答案试图说服你，在这种特殊情况下，通过施放一堆额外的咒语，这是可能的。但是，最安全的方法是将您的思维切换到 DTO，即数据传输对象，这是一种模式，您可以在其中创建额外的"仅数据"类层，这些类轻巧且安全，可以通过网络序列化和发送。
有很多很棒的文章解释了如何使用DTO模式和一些额外的支持技术(如AutoMapper(公开数据。您将轻松找到详细信息，并可以回来寻求进一步的答案。
你没有违反"POCO 规则"。异常中提到的"动态代理"是从WorkSession实体派生的类，但它不是在代码中派生的，而是在运行时动态派生的。默认情况下，实体框架执行此操作是为了在将导航属性(可能还有标量属性(标记为 virtual 时使延迟加载和动态更改跟踪成为可能。
当您打算使用 WCF 序列化实体时，应禁用动态代理创建。只需在从数据库加载实体之前在上下文上设置一个标志即可执行此操作：
context.Configuration.ProxyCreationEnabled = false;
var worksessions = context.WorkSessions.....ToList();
加载的worksessions现在属于真正的运行时类型WorkSession，而不是动态代理类型，WCF 不应再抱怨。