プロパティ名の変更のために失敗から自分自身を守るために（関連するDbテーブルのいくつかの列名を変更したためにpocoクラスを再生成するとします）、プロパティ名を保持する定数文字列をdecalreすることをお勧めします内部？プロパティ名をパブリック定数文字列に格納するのは良い方法ですか？
public const string StudentCountPropertyName = "StudentCount";
public int StudentCount {get;set;}
例：データバインディングについて考えてみましょう。 DataFieldName属性に明示的にプロパティ名を入力します。
これは良い考えではありませんが、より安全で安全な方法はありますか？
1つの観点から：このプロパティ名を複数回使用すると、それは良い方法です。それはリファクタリングで確実に役立ちます。たとえば、プロパティ名を変更する場合は、このconstも変更する必要があります。
別の観点からは、10のプロパティを持つクラスに10個の追加のconstがあると、醜いと思うでしょう。 constや明示的な名前の入力を避けたい場合は、リフレクションを通じてプロパティ名を取得することもできます。
このような方法を使用するかどうかは、自分で決める必要があります。
「マジックストリング」を定数に移動することは、常にIMHOです。
次の例のように、あなたの特性を「選ぶ」にラムダ式を使用することを検討できます。
GetDataFieldName(studentCollection => studentCollection.Count)
あなたは反射のビットを使用して、GetDataFieldNameを自分で実装する必要があります。 MVCからHtmlHelperExtensionsを見ると、それがどのように実行できるかを見ることができます。これは最も安全な方法です。何か問題が生じたときにコンパイル時エラーが発生し、既存のリファクタリングツールを使用して容易にプロパティの名前を変更できます。
プロパティがインライン展開されるのはどれくらいですか？ –
@ValentinKuzub：インライン化はメソッドのセマンティクスを変更しないため、オブジェクトのセキュリティまたはアクセス可能性を低下させることはできません。インライン展開は厳密にはJITの最適化であり、プログラマとして心配する必要はありません。 –
プロパティがインラインリフレクションベースのプロパティ名解決に失敗した場合、それは私の懸念です –
この「魔法の文字列」や「魔法の数字」をある種の強力な型指定のストアに入れるのはよくある習慣だと思います。
あなたが考えることができるものは、それをアスペクト指向の方法でコーディングすることです。
たとえば、notifypropertychagnedの呼び出しは、PostSharpのようなaopフレームワークで実装された属性を使用して実現できます。
[NotifyChange]
public int Value {get;private set}
私は名前が多くの場所で使用されているならば、それだけで変更することが容易になるだろうと仮定し、このツールは、いくつかの欠点をも持っているが、私は、彼らはあなたの仕事
を大幅に節約することができシナリオがあると思いあなたのコメントに記載されている定数を使用してください。
ただし、データベースの列名とオブジェクトのプロパティ名を変更すると、概念的なデータモデルが変更されます。どのくらいの頻度でこれが起こると思いますか？プロジェクトの初期段階では、概念的なモデリングと実装がデベロッパーチーム全体で並列化されていますが、これは非常に流動的ですが、初期の概念モデリングが完了すると（フォーマルな意識的な方法でも有機的なものでも）このような基本的なことは変わることはまずありません。このような理由から、私はこれを行うのは比較的珍しいと思っています。この手法は、エッジの場合にのみ生産性が高くなります。
再度、定数*はこれまでどおり変更するつもりはありません。 public定数を変更するとバイナリ互換性が損なわれます – Dyppl
これは非常に真ですが、これは 'パブリッシュ'アセンブリを出荷する場合、つまりアセンブリの新しいバージョンを削除した後にコードを再コンパイルする場合とそうでない場合があるサードパーティが使用する場合にのみ関係します。内部使用アセンブリでは、定数を変更することが可能です。しかし、私は、それでもやはり「一定」という概念の誤用が幾分残っていることに同意します。 –
もちろんです。いい考えだね。
ところで、私はこれらの種類のものが、後でこれらの設定をオーバーライドすることで、アプリケーション設定ファイルでそのようなことを定義できるので、アプリケーション設定に保存する方が良いと主張します。
データベースやPOCOなどの変更があれば再コンパイルする必要はなく、2010年のような新しいVisual Studioのバージョンでは、「公開」アクセシビリティの設定を生成するように指示することができます。厳密に型付けされた設定で、それらを含むアセンブリを参照します。
日中、定数の代わりにDataBindingSettings.StudentCountPropertyNameでコードを変更します。
"設定でデータバインディングを設定する"というより、使いやすく、読みやすく、読みやすくなります。
アプリケーションの設定についての詳細を、このMSDNの記事をチェックしてください：
私は完全にあなたの質問を理解していれば、私は知りませんが、私は右のそれを理解すれば、私が使用しているだろうそのための例としては、データベース内の特定の列にプロパティをマップするために使用するLinqでのColumnAttributeの使用があります（http://msdn.microsoft.com/en-us/library/system.data.linq .mapping.columnattribute.dbtype.aspx）。この例のように：
[Column(Storage="ProductID", DbType="VarChar(150)", CanBeNull=False)]
public string Id { get; set; }
DataFieldNameを使用することはありません。厳密に型指定されたオブジェクトに対してDataBindを使用します（もちろん、今後の実装を簡単に変更できるように、上記のプロパティを使用するクラスへのインターフェイスも作成します）
これらの定数の存在をどのように利用することを提案しますか？ –
次のようなものを想像してみてください：DataFieldName = "<％= StudentCollection.StudentCountPropertyName％>" – pencilCake