使用 DTO，在 WCF 中更新 BLL 属性的正确方法是什么？答案

【问题标题】：Using a DTO, what is the correct way to update a BLL property in WCF?使用 DTO，在 WCF 中更新 BLL 属性的正确方法是什么？
【发布时间】：2012-05-13 03:27:34
【问题描述】：

现在已经到了 WCF 地狱的第 74 级，我被判处永远的 DTO 混乱。我非常习惯于像这样明智地封装对象/属性设置机制，其中在构造函数中设置了一些默认值，并且重置该值会“弄脏”对象：

public class SomeObject
{
    private int someValue;

    public int SomeValue
    {
        get { return someValue; }
        set 
        { 
            someValue = value; 
            // now SomeObject.IsDirty = true;
        }
    }

    public SomeObject(int someDefaultValue)
    {
        someValue = someDefaultValue;
    }
}

DTO 似乎强烈反对这种简单的构造，我假设（但不知道）通过 DataContract 和 DataMember 装饰器。当我单步执行时，我看到堆栈中有一些我无法闯入的调用，但这大致是结果：

[DataContract]
public class SomeObjectDTO
{
    private int someValue;

    [DataMember]
    public int SomeValue
    {
        get { return someValue; }
        set
        {
            // apparently the set is getting called by the constructor?
            someValue = value;
        }
    }

    public SomeObjectDTO(int someDefaultValue)
    {
        //apparently no one cares what I want to do here? next line won't fire
        someValue = someDefaultValue;
    }
}

我可以看到构造函数参数的值流入set，但我不知道如何，我看不到如何将mapper-constructed-default值与user-edited-property分开-value-and-now-it-must-be-returned-to-the-service EDIT.

我确信这是对 DTO 的误用，但我看不到正确的 WCF 方法来处理这些非常基本的常见情况：

如何将属性值的实例化与编辑它？
如果您有一个具有 50 个属性的对象/DTO，您如何知道用户何时更改了其中的 49 个属性，以及如何将这些更改一次性发送回 BLL 母对象船？李>

【问题讨论】：

您的 OperationContracts 上是否使用了 DTO？
是的，这就是他们创作的全部目的。

标签： wcf events c#-4.0 properties dto

【解决方案1】：

对这个问题缺乏回应可能与我问的不够清楚有关，但它的要点对 WCF 初学者很重要，我怀疑这里的 WCF 权威很少...无论如何我可以现在自己回答，以防其他人被困在一个月前的位置。

如果您单步执行使用 WCF 的 WCF 操作，则很容易误解正在发生的事情，除非您仔细观察您的调用堆栈。一些SomeObjectDTO 可能会在服务器端正确构造，您可能认为调用已完成......只是看到它再次通过。我想 MSFT 没有办法记录这一点，但是“第二个”构造——它将忽略任何使用参数的构造函数——实际上是 反序列化。对于DataContract的初学者，这一点我怎么强调都不为过：你会根据服务端的一些规则来构造你的对象，然后它会（除非你已经实现了自己的序列化器）100% 失明地被序列化和反序列化，这在客户端会产生一个新的、无参数的构造，这意味着 除了set 方法之外，你不能使用任何东西来构造它。这是因为它没有被“构建”，而是从关于自身的一串元数据中重建（或者，正如某些人所说，“重新水化”）。它只是属性，串在一起，在一个父元素下。

至于将一些IsDirty 逻辑构建到DataMember 中的问题，算了吧。这些对象是传输机制，一次性的，只有可以序列化的东西一样聪明，这很愚蠢：名称-值对的列表。了解 50 个属性中的 1 个何时更改或未更改的唯一方法是在一些更智能（至少半）持久的环境中比较对象之间的值：这是什么？不，不是吗？哦，很脏。乘以 50。或 1000。或多少。

所有这一切的有趣之处在于，在 WCF 中实现的 SOA 和“解耦”代表了发展的巨大飞跃。他们不;它们代表了一种非常薄弱的共识，一种最小公分母的方法，当分离到单个应用程序级别时，需要大量的复制工作。最佳情况下，复制是对模型、操作和协议的联合故障排除；在最坏的情况下，您将编写 n 个版本的代码来处理 n 个情况。这变得霓虹灯可见，因此在 .NET 到 .NET 的实现中更加痛苦，如果 .NET 是您的平台并且 MSFT 堆栈您的环境，那么这是一个完全反对使用 WCF 的有力论据。投入数以千计的隐藏配置默认值等待以零准确异常报告来破坏操作，您可以将其称为一天，或者比您当前的范围多三到四个人月。

【讨论】：