プロパティで構造体またはクラスフィールドをラップすると、そのフィールドへのすべてのアクセスが「getter」メソッドと「setter」メソッドを経由するように強制されます。これにより、検証や遅延初期化などのロジックを追加できるようになります。さらに、クラスフィールドの場合、一部のインスタンスには適用されるが他のインスタンスには適用されないロジックがある可能性があります。プロパティが仮想でない場合、そのようなロジックを効率的に実装するのは難しいかもしれません（たとえば、静的を定義しVerySpecialInstanceてプロパティゲッターに言わせる必要があるかもしれませんif (this == VerySpecialInstance) GetSpecialProperty(); else GetOrdinaryProperty();）が、それは可能です。
ただし、構造体（eg System.Drawing.Point）のセマンティクスにより、特定の読み取り/書き込みプロパティがそのタイプに対して有効な任意の値で書き込まれる可能性がある場合、書き込みはその値を変更する以外の副作用はなく、常に戻ります。最後に書き込まれた値（存在する場合）。書き込まれていない場合は、そのタイプのデフォルト値として読み取られます。また、型を使用するコードがそのような仮定に依存する可能性が高い場合、値を保持するフィールドではなく読み取り/書き込みプロパティを使用することでどのようなメリットが得られるかはわかりません。
Microsoftがフィールドではなくプロパティを使用するという事実は、に変換されるPoint.Xため、歴史的に混乱を引き起こしました。定義の内部を見なければ、そのメソッドがフィールドを変更せずに目的の効果を達成するかどうかを判断することはできません。問題の構造体; 今日のC＃コンパイラは、それが機能しないと推測し、プロパティセッターが実際に正常に機能するタイプがいくつかある場合でも、その構成を禁止します。プロパティではなくフィールドであり、構造体を変更する2つの安全な方法は、フィールドに直接アクセスするか、構造体をとして渡すことであるとMicrosoftが言った場合MyList[3].X = 4;MyList[3].Set_X(4)Set_XstructXrefミューティングメソッドのパラメーター（構造体タイプの静的メソッドの場合、パブリックフィールドにアクセスできます）の場合、このような当て推量は必要ありません。
読み取り/書き込みプロパティではなく公開された構造体フィールドを使用すると、パフォーマンスとセマンティックの明確さの両方が向上することを考えると、構造体フィールドをプライベートにしてプロパティでラップする理由は何ですか？データバインディングにはプロパティが必要ですが、とにかく構造体タイプでは機能しないと思います（構造体のコピーを作成してから、元のプロパティのプロパティを1つの値に設定し、複製の対応するプロパティを別の値に設定する場合、どの値を使用する必要がありますか）バインドされたオブジェクトに報告されますか？）私が知らない構造体プロパティの利点はありますか？
個人的には、多くの場合、「理想的な」構造体は、公開されたパブリックフィールドのリストであり、パラメーターがこれらのフィールドの初期値であるコンストラクターであると思います。そのような構造体は、最適なパフォーマンスと予測可能なセマンティクスを提供します（フィールドのタイプと名前を除いて、他のすべてのそのような構造体と同じように動作します）。基になるフィールドを単に読み書きする以外に何もできない場合に、読み取り/書き込みプロパティを優先する理由はありますか？