15

ビジネス オブジェクトを WCF 経由で転送するには、いくつかの DTO クラスを作成する必要があります。

これらは機能のない単なるデータの袋であるため、フィールドを使用できない理由はありますか、またはそれらをプロパティとして適切に公開する正当な理由はありますか?

//fields
[DataContract]
class CustomerDTO
{
    [DataMember] public int     Id;
    [DataMember] public string  Name;
}

//or properties?
[DataContract]
class CustomerDTO
{
    [DataMember] public int    Id               { get; set; }
    [DataMember] public string Name             { get; set; }
}
4

6 に答える 6

6

これらは機能のない単なるデータの袋であるため、フィールドを使用できない理由はありますか

ここでは、パブリック フィールドに対する強力な議論はありません。ただし、カプセル化の通常の議論が成立しないように、DTO 内にロジック (動作) がないためだけであることを認識してください。

私はまだプロパティを好むでしょうが、ここでは実際には必要ありません。

于 2012-05-31T10:02:49.173 に答える
3

どちらでも使用できます。パフォーマンスに影響しないため、パブリック フィールドでは機能しないシリアライゼーション フレームワークなどに遭遇した場合に備えて、プロパティを使用する方が安全です。

サービス側でパブリック フィールドを使用する場合でも、WCF プロキシ生成では、クライアント側でパブリック プロパティとそのバッキング プライベート フィールドを使用してこれらの DTO が作成されることに注意してください。どうしてもそうしたくない場合は、サービスとクライアントの間で DTO ライブラリを共有する必要があります。

于 2012-05-31T10:34:10.823 に答える
1

属性はパブリックフィールドとプロパティのDataMember両方で機能するため、どちらも可能です。ただし、プロパティに固執することをお勧めします。

特に、StyleCopを使用している場合は、ルールSA1401に違反することになります。

このルールが存在する理由は実際には当てはまりませんが、継続的インテグレーションサーバーでビルドの一部としてStyleCop検証を実行している場合は、メンテナンスの問題が発生します。

于 2012-05-31T10:09:06.960 に答える
0

フィールドを直接公開することは決してありません。ほとんどの企業は、標準でこれを禁止しています。事実上、カプセル化を完全に破棄します。より複雑なものの貧弱な表現であるDTOは、そのプロパティがカプセル化をほとんど壊すため、奇妙なケースです。個人的には、その目的のためにプロパティを使用します。また、フィールドを直接微調整している場合はそれほど簡単ではない必要がある場合は、「ダーティ」機能などを実装できます。

于 2012-05-31T10:00:10.870 に答える