WCF – 域对象和IExtensibleDataObject

概述典型场景我们在内部使用旧版 XML Web Services来在服务器场和多个分布式本地客​​户端之间进行通信.没有第三方参与,只有我们自己和我们的客户使用我们自己的应用程序. 我们正在考虑从XML WS转向基于WCF /基于对象的模型,并一直在尝试各种方法.其中一个涉及通过线路直接传输域对象/聚合,可能调用它们上的DataContract属性. 通过使用DataMembers上的Order属性使 典型场景我们在内部使用旧版 XML Web Services来在服务器场和多个分布式本地客​​户端之间进行通信.没有第三方参与,只有我们自己和我们的客户使用我们自己的应用程序.

我们正在考虑从XML WS转向基于WCF /基于对象的模型,并一直在尝试各种方法.其中一个涉及通过线路直接传输域对象/聚合,可能调用它们上的DataContract属性.

通过使用DataMembers上的Order属性使用IExtensibleDataObject和DataContract,我们应该能够处理简单的属性版本控制问题(请记住,我们控制所有的客户端,并且可以轻松地强制更新它们).

然而,我不断听说我们应该通过电线使用专用的,仅传输数据传输对象(DTO).

为什么？真的还有理由这样做吗？我们在服务器端和客户端使用相同的域模型,当然只有在被视为正确和“必要”时,才能预先收集集合.集合属性通常利用服务定位器原理和IoC来调用基于Nhibernate的“服务”来直接(在服务器端)提取数据,以及客户端上的WCF“服务”客户端与WCF服务器场通信.

那么为什么我们需要使用DTO？

解决方法 根据我的经验,DTO最有用的是：

>严格定义将通过电线发送的内容,并具有专门用于该定义的类型.
>隔离您的应用程序,客户端和服务器的其余部分,以备将来的更改.
与非系统的互 *** 作性. DTO当然不是一个要求,但它们可以更容易地设计“安全”类型.

在您的场景中,这些设计功能可能并不重要.我已经使用WCF与严格的DTO和共享的域对象,并在这两种情况下,它的功能很棒.我通过电线发送域对象时注意到的唯一的事情是,我倾向于发送更多的数据(以意想不到的方式),然后我需要.这可能是因为我没有任何其他的WCF经验;但是如果你选择去那条路线,那么你一定要谨慎.

总结

以上是内存溢出为你收集整理的WCF – 域对象和IExtensibleDataObject全部内容，希望文章能够帮你解决WCF – 域对象和IExtensibleDataObject所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。