Model.is ___-それはプロパティまたは方法である必要がありますか？

Question

私がドメインのモデルを設計するとき、彼らはほとんど常にいくつかを持っていることになります .IsSomething それらの機能。 IsNew と IsDirty データの持続目的で一般的です、 IsValid ビジネスルールの検証の場合でも IsFraudulent 現在のプロジェクト（より多くのビジネスルールの検証）など。これらが他のプロジェクトによって実装されていると思うたびに、それらはほとんど常にメソッドとして行われます。しかし、私はそれに特別な理由があるかどうか疑問に思っています。

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

プロパティに関するシリアル化の問題がある可能性があると思います。豊富なドメインモデルは、ロジックと機能が含まれていることを考えると、とにかくシリアル化しない傾向がありますが、サービスの境界を越えて何かを移動する必要があるときはいつでも、一般に、最初に定義されたDTO構造に平らになります。

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

（ただし、接線に関連しています 答えはすでに与えられています, 、拡張プロパティは、このようなものの一貫性に本当に役立ちます。私にはたくさんあります IsSomething() 拡張メソッド、通常オン System.String, 、ドメイン固有のロジックを実装するため。しかし、プロパティが進むべき方法であっても、拡張機能と一貫してメソッドに固執したいと思うかもしれません。）

Answer 1

私は以下のためにプロパティを使用します。

1. 何らかの形でオブジェクトを説明しているので、概念的にはその特性、その特性

2. パラメーターは要求しません

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

Answer 2

プロパティへのアクセスを仮定して：

• 副作用はありません
• 「合理的に迅速」です（ええ、非常に羊毛...）

それから私はそれを財産にしない理由はないと思います。シリアル化は問題であってはなりません - ほとんどのシリアル化スキームは、プロパティを一時的なものとしてマークする方法を提供します（つまり、シライラ化されていない）。