过去五个月我一直在开发一个应用程序，刚刚遇到了这个问题。
我们正在使用 EF5，类似于 this question ，我设计了类层次结构，使所有实体类都派生自抽象基类，以强制实现验证接口(interface)。我们还在实体类中使用验证属性。
一切都工作正常，直到我开始尝试使用 WCF 服务中的实体类。我收到了一堆序列化异常，并一直试图找出我在设计中打破的“POCO”规则。 This article告诉我这个类(显然......)不能是抽象的，但由于我的类是从抽象类派生的，我是否可能违反了我不知道的规则？
更新:这是我正在努力解决的异常(exception):
System.Runtime.Serialization.SerializationException, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Type 'System.Data.Entity.DynamicProxies.WorkSession_63308485A9007DE087FF55AD9F246FD677863AA39AD56FEF4586AB87E21832DD' with data contract name 'WorkSession_63308485A9007DE087FF55AD9F246FD677863AA39AD56FEF4586AB87E21832DD:http://schemas.datacontract.org/2004/07/System.Data.Entity.DynamicProxies' is not expected. Consider using a DataContractResolver or add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.
最佳答案
由于您的 POCO 使用延迟加载，因此您不会从 EF 获取实际类型，而是获取代理，以便自动实现导航属性以进行延迟加载。
我的建议是忘记从 Web 服务公开域对象的想法。我敢打赌，会有一些答案试图让你相信，在这种特殊情况下，通过施放一堆额外的咒语，这是可能的。然而，最安全的方法是将您的想法转向DTO，即数据传输对象，这是一种模式，您可以在其中创建额外的“仅数据”类层，这些类轻量且安全，可以序列化并通过电线。
有很多很棒的文章解释了如何使用 DTO 模式和一些额外的支持技术(例如 AutoMapper)公开数据。您将轻松找到详细信息，并且可以回来寻求进一步的答案。
关于c# - 未被发现的 POCO 类要求，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19058220/