1

现在已经到了 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 似乎强烈反对这种简单的构造，我假设（但不知道）通过DataContractandDataMember装饰器。当我单步执行时，我看到堆栈中有一些我无法进入的调用，但这大致是结果：

[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 编辑。

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

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

1 回答 1

0

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

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

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

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

于 2012-06-13T06:16:23.050 回答