エンティティオブジェクトにその属性のドメインが含まれている場合、ここで一度読んだカプセル化の側面を実験的に適用したいと考えています。そのCostCentreプロパティには、有効なコストセンターのリストが含まれています。このようにして、Extensionの編集フォームを開くと、フォームを初期化するときにCostCentreオブジェクトに通常アクセスする1つのExtensionオブジェクトだけを渡す必要があります。エンティティフレームワークとカプセル化
これは、グリッド（telerik RadGrid）にバインドされている拡張機能のリストがある場合に適用され、グリッド上で編集コマンドを処理します。編集フォームを作成してExtensionオブジェクトを渡して、ここで編集フォームをExtensionIDに渡してフォームにオブジェクトを作成します。
私がここで実際に求めているのは、これをこのようにする指針、またはここで説明したものと同様のものを達成するための「適切な」方法です。
データソースによって異なります。コストセンターのリストをデータベースから取得する場合は、1つのアプローチになります。それが所定の値の短いリスト（Yes/No/Maybe Soのような）であれば、プロパティ属性がそのトリックを行うかもしれない。環境ごとに設定可能である必要がある場合は、IoCまたはプロバイダパターンが最適です。
あなたの問題は、以前のプロジェクトで行ったカスタムアドホック検索ページと似ていると思います。我々は、ルックアップ値メソッドとそれらの関係に対するいくつかの所定の「ポインタ」を含む属性で、エンティティクラスとプロパティを修飾しました。次に、これらの属性を使ってLINQ式を動的に生成し、実行時にそれを実行することで、ドロップダウンと自動補完のテキストボックスリストを生成するカスタムのUIコントロールを1つ作成しました。ユーザーが何をしていたとしても。
これは基本的に3つの可動部分、すなわちA）データアクセスオブジェクトの属性B）中間層コンパイルおよび生成動的LINQ表現の '属性ファサード'メソッド、およびC）呼び出されたカスタムUIコントロール私たちの中間層のサービス方法。
時にはこれらのバックファイアのような計画がありますが、私たちの場合は素晴らしい結果でした。オブジェクトを属性で装飾し、単一の論理パスを作成するだけで、必要なコードを最小限に抑えながら、必要な処理を実行するだけの十分な能力が得られ、定型文も完全になくなりました。しかし、このアプローチはあまり設定可能ではありませんでした。これらの属性をコードにコンパイルすることで、アプリケーションをデータソースに密接に関連付けることができました。この特定のプロジェクトでは、それはクライアントの内部システムであり、プロジェクトのタイムラインに適合していたため大したことではありませんでした。しかし、プロバイダパターンでロジックを実装したり、Castle Projects IoCのようなものを使用している「実際の製品」では、設定能力が大幅に向上しています。これの欠点は、管理しなければならないことが多く、配備などで間違っている可能性があることです。