这种 WCF 序列化方法合理吗？

Question

我正在考虑使用 WCF 来执行客户端/服务器、UI/数据库层，我的想法是我会使用 WCF 服务来读取 DataRow，填充类的属性，然后将其返回给 UI 客户端（这是 Windows 端到端）。

我从 DLL 中的一个类开始，并在 UI 和服务器之间共享 DLL。服务器读取 DataRow，并且类知道如何从 DataRow 中填充自己。该类具有带有私有支持变量的公共属性，但是当从 DataRow 填充时，该类直接写入支持变量。然后将类的实例传回 UI。

UI 反序列化类。该类具有公共属性，并且设置器都执行 INotifyPropertyChanged 内容以支持绑定。到目前为止，还没有正常。

我从 [DataContract] 和 [DataMember] 属性开始，但注意到当我的对象实例在 UI 上被反序列化时，它会调用类实例的公共属性设置器 - 这反过来会触发每个属性的“已更改”事件。

为了解决这个问题，我读到我可以使用 IXmlSerializer。所以我去掉了属性，支持了 IXmlSerializer 接口，使用 ReadXml() 方法直接写入公共属性后面的后备变量。

这一切都很好（除了现在必须有一个无参数的构造函数），但这合理吗？这就是事情应该如何运作的方式吗？

我是否应该有一个共享类，它从 UI 知道 INotifyPropertyChanged，并且从服务器端知道如何从 DataRow 构造自己。我应该将所有这些逻辑放在其他地方，并使用 XSD 定义类吗？

问题是我可能可以解决我遇到的问题（例如如何反序列化可空类型），但我不确定是否有更好的方法。除了 Windows 到 Windows WCF 通信之外，我没有可预见的需要支持任何东西，所以我实际上并不关心 XML 是什么样子（或者它是否存在）。

指针将不胜感激。

谢谢。

Answer 1

一种可能的解决方案是在服务器端维护一个合同（可以通过 [DataContract]、[DataMember] 进行序列化），在客户端维护一个实体。任何给定的服务方法都会返回合同，但您不会直接调用服务。相反，在中间放置一个代理。代理将调​​用服务方法，从合约转换为实体，然后返回实体。

这样，您的前端只关心它的实体（因为它只与代理对话 - 从不直接与服务对话）并且根本不必担心合同。而且您不必自己做时髦的序列化工作:)