2

在过去的五个月里，我一直在开发一个应用程序，但遇到了这个问题。

我们正在使用 EF5，并且与此问题类似，我将类层次结构设计为具有从抽象基类派生的所有实体类，以强制实现验证接口。我们还在实体类中使用验证属性。

在我开始尝试使用 WCF 服务中的实体类之前，一切都运行良好。我得到了一堆序列化异常，并且一直试图弄清楚我在设计中打破了哪些“POCO”规则。 这篇文章告诉我这个类（显然......）不能是抽象的，但是由于我的类是从抽象类派生的，我是否可能违反了我不知道的规则？

更新：这是我正在努力解决的例外情况：

System.Runtime.Serialization.SerializationException，mscorlib，版本=4.0.0.0，文化=中性，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. 考虑使用 DataContractResolver 或将任何静态未知的类型添加到已知类型列表中 - 例如，通过使用 KnownTypeAttribute 属性或将它们添加到传递给 DataContractSerializer 的已知类型列表中。

4

2 回答 2

2

由于您的 POCO 使用延迟加载，因此您不会从 EF 获取实际类型，而是从代理获取导航属性，以便为延迟加载自动实现导航属性。

我的建议是忘记从 Web 服务公开域对象的想法。我敢打赌，会有一些答案试图让你相信，在这种特殊情况下，通过施放一堆额外的咒语，这是可能的。但是，最安全的方法是将您的想法切换到DTO，数据传输对象，在这种模式下，您可以创建一个额外的“仅数据”类层，这些类轻巧且可以安全地序列化和通过网络发送。

有很多很棒的文章解释了如何使用 DTO 模式和一些额外的支持技术（如 AutoMapper）来公开数据。你会很容易找到细节，你可以回来寻求进一步的答案。

于 2013-09-27T20:01:15.997 回答
1

您没有违反“POCO 规则”。异常中提到的“动态代理”是从您的实体派生WorkSession的类，但它不是在您的代码中派生的，而是在运行时动态地派生的。如果您已将导航属性（可能还有标量属性）标记为virtual.

当您打算使用 WCF 序列化实体时，应禁用动态代理创建。您可以通过在从数据库加载实体之前简单地在上下文上设置一个标志来做到这一点：

context.Configuration.ProxyCreationEnabled = false;

var worksessions = context.WorkSessions.....ToList();

现在加载worksessions的是真正的运行时类型WorkSession，而不是动态代理类型，WCF 不应该再抱怨了。

于 2013-09-27T20:02:02.403 回答