Model.Is ___ - プロパティまたはメソッドである必要がありますか？

Question

ドメインのモデルを設計するとき、ほとんどの場合、それらの上にいくつかの.IsSomething機能があります。 IsNewおよびIsDirtyはデータ永続化の目的では一般的ですが、ビジネスルールの検証にはIsValid、さらに現在のプロジェクトではIsFraudulent（ビジネスルールの検証）などです。しかし、私はそれには特別な理由があるのか​​疑問に思います。

私はオブジェクトとメソッドを何らかのアクションを実行するものとして記述しているようにプロパティを参照する傾向があります。これらは実際にはアクションを実行しません。コードは呼び出されたときに動的に決定され、読み込み専用ですが、メソッドではなくプロパティとして適合しているため、コードが含まれています。

プロパティでシリアル化の問題が発生する可能性があります。リッチド・ドメイン・モデルは、ロジックと機能が含まれているため、シリアル化がうまく行かない傾向がありますが、サービス境界を超えて何かを移動する必要があるときは、まず定義済みのDTO構造に展開します。

しかし、誰か他の人がこの問題について洞察しているのだろうか？これらをプロパティとしてではなくメソッドとして実装する理由はありますか？

（接線方向に関連し、拡張プロパティは本当にこのような何かに一貫して役立つだろうan answer has already been givenのに。私は、ドメイン固有のロジックを実装するために、通常System.String上IsSomething()拡張メソッドの数を、持っている。しかし、プロパティが途中であっても、行くために、私は拡張子を持つ一貫性を保つための方法に固執することをお勧めします）

Answer 1

ので、私はプロパティを使用します。それはすべてのパラメータ

を要求しません何らかの方法でオブジェクトを記述し、その

その性質、概念的にその特性

1. 基本的には、特定のデータを取得するだけで、スタンドアロンのアクションや変更は行いません。

Answer 2

プロパティにアクセスすると仮定すると：。

• には副作用
• を持っていないこと「のreasonablですyスピード "（ええ、非常にウール...）

私はそれをプロパティにしない理由はありません。シリアライゼーションは問題ではありません。ほとんどのシリアライゼーション・スキームは、プロパティを一時的（つまり、シリアライズしない）としてマーキングする方法を提供します。