7

読み取り専用の Id フィールドを持つクラスを作成しようとしていますが、オブジェクトが WCF サーバーを通過するときに値を保持するのに問題があります。

[DataMember]メソッドがないため、パブリック プロパティに属性を設定することはできませsetん。この値を外部手段で変更したくないため、可能であればそのままにしておきたいと思います。[DataMember]部分信頼環境ではエラーがスローされるため、プライベート フィールドに属性を設定できません。

public class MyClass
{
    private int _id;

    public int Id 
    { 
        get { return _id; } 
    }

    private string _otherProperties;

    [DataMember]
    public string OtherProperties
    {
        get { return _otherProperties; } 
        set { _otherProperties = value; }
    }
}

プロパティを公開せずに WCF サーバーを通過するときに Id フィールドの値を維持する方法はありますか?

4

3 に答える 3

9

あなたはこれを行うことができます：

public int Id
{
     get;
     private set;
}

これにより、ユーザーが実際に ID 値を設定できないようにしながら、デシリアライザーを満足させ続けることができます。コンストラクターまたは別のプロパティのセッターで設定する必要があります。

ただし、DTO はダム コンテナーである必要があるという点で、Sanders に同意します。

于 2010-09-29T14:35:53.210 に答える
7

一般的に言えば、データ コントラクト クラスは、ロジックや深い意味を持たない非常に軽量なデータ転送オブジェクトである必要があります。クラウド全体でデータを転送するための単なるコンテナーです。それらは、一連のパブリックな読み取り/書き込みプロパティのみを持つパブリック クラスである必要があります。ビジネス ロジック クラスでは、これらをいくつかの内部ビジネス エンティティに変換し、データを送信するときにその逆を行う必要があります。

これにより、データ転送モデルが内部エンティティ モデルから分離され、最適な保守性が確保され、直面している問題 (OO 設計の問題が WCF の動作動作と競合する場合) を回避できます。

非常に小規模なプロジェクトでは、別のモデルを維持するオーバーヘッドに見合わない場合があります。AutoMapperは、必要な手作業を最小限に抑えるのに役立ちます。

あなたの特定のシナリオについて言えば、問題のステートメントを正確に理解しているかどうかはわかりません。一部のフィールドを変更したくないですか? しかし、このフィールドはデータ モデルの一部にすぎません。データ モデルの一部は「変更」されることはありません。「古い」データはなく、クライアントが構成するデータだけです。クライアント コードは、データ オブジェクトをサーバーに送信するだけです。サーバーがクラスの 1 つのメンバーを気にしない場合は、それを無視する必要があります。

データ コントラクト オブジェクトのインスタンスがサーバー上に存在し、クライアントがそれらを操作するのを待つようなものではありません。読み取り専用フィールドは、このようなシナリオでは概念的に意味があるかもしれませんが、WCF ではそうではありません。クライアントはオブジェクトを作成してサーバーに送信するだけです。サーバーに一部のデータをリッスンさせたくない場合は、そのデータをデータ モデルに追加しないか (場合によっては、特定のユーザーなどに対してのみ必要な場合)、不要な場合にサーバーに無視させます。

于 2010-09-29T14:33:00.577 に答える
1

いいえ。データメンバーは、シリアライズ可能にするためにゲッターとセッターを持っている必要があります。IDがクライアントで変更されていないことを検証するのはサービスの責任です。

于 2010-09-29T14:09:54.950 に答える