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 は、この単純な構造に強く反対しているように見えますが、デコレータ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ことはわかりますが、方法がわかりません。また、ユーザー編集プロパティの値と現在からマッパー構築デフォルト値を分離する方法もわかりません。 - サービスに返却する必要があります EDIT.

これは DTO の誤用だと確信していますが、これらの非常に基本的で一般的なケースを処理するための正しい WCF の方法がわかりません。

  • プロパティ値のインスタンス化とその編集をどのように分離しますか?
  • たとえば、50 個のプロパティを持つオブジェクト/DTO がある場合、ユーザーがそれらのうち 49 個を変更したことをどのように把握し、それらの変更を BLL マザー オブジェクト シップに 1 回で送信するにはどうすればよいでしょうか?
4

1 に答える 1

0

この質問に対する回答の欠如は、私の明確な質問の欠如と関係があるかもしれませんが、そのポイントはWCF初心者にとって重要であり、SOに関するWCF当局はほとんどいないと思われます... とにかく、私は今答えられます1 か月前の状態で他の誰かが立ち往生した場合に備えて。

WCF を使用する WCF 操作をステップ実行すると、コール スタックを注意深く監視しない限り、何が起こっているのかを簡単に誤解してしまいます。サーバー側で正しく構築されるものSomeObjectDTOもあり、呼び出しが完了したと思うかもしれません...再度ステップスルーするだけです。MSFT がこれを文書化する方法はないと思いますが、パラメーターを使用するコンストラクターを無視する「2 番目の」構築は、実際には deserializationです。初心者のためDataContractに、これを十分に強調することはできません: サービス側のいくつかの規則に従ってオブジェクトを構築すると、(独自のシリアライザーを実装していない限り) 100% 見えないところでシリアライズおよびデシリアライズされます。クライアント側は、新しいパラメーターなしの構造になります。つまり、setメソッド以外を使用して構築することはできません。これは、それが「構築」されているのではなく、それ自体に関する一連のメタデータから再構築されている (または、一部の人が言うように「再水和」されている) ためです。それは、親要素の下にまとめられた属性に他なりません。

いくつかのIsDirtyロジックが に組み込まれているという問題についてはDataMember、忘れてください。オブジェクトは転送メカニズムであり、使い捨てであり、シリアル化できるものと同じくらいスマートですが、それはかなりばかげています: 名前と値のペアのリストです。50 個のプロパティのうち 1 個がいつ変更されたか、または変更されていないかを知る唯一の方法は、よりスマートな (少なくとも半) 永続化された環境で、オブジェクト間で値を比較することです。いいえ、そうではありませんか？あ、汚い。50 倍。または 1000 倍。またはいくらでも。

このすべてで面白いのは、WCF に実装されている SOA と「デカップリング」が開発の大きな飛躍を表しているという考えです。彼らはしない; それらは非常に弱いコンセンサスであり、個々のアプリケーション レベルに展開すると、かなりの労力を必要とする最小公分母のアプローチを表しています。モデル、アクション、およびプロトコルのフェデレーションのトラブルシューティングに複製が費やされるという最良のシナリオ。最悪のシナリオでは、nを処理するためにnバージョンのコードを記述します。ケース。.NET がプラットフォームであり、MSFT が環境をスタックしている場合、これは WCF をまったく使用することに対する強力な議論です。ゼロの正確な例外レポートで操作を爆破するのを待っている 1 億の非表示の構成のデフォルトを投入すると、現在のスコープよりも 1 日、または 3 ～ 4 人月多く呼び出すことができます。

于 2012-06-13T06:16:23.050 に答える