CustomAttributes を使用しない理由はありますか?

Question

これは主に、何か理由があればコメントを求めるものです。 ない この道を進んでください。

CodeSmith が生成した多層アプリケーションがあります。UI レベルでは、いくつかの必須フィールドが必要です。必須フィールドは、バインドされたエンティティのフィールド値によって異なります。私がやろうと考えているのは、マネージャーにエンティティを読み込むときに true または false を設定できるエンティティの各プロパティに「PropertyRequired」CustomAttribute を追加することです。次に、Reflection を使用してプロパティをクエリし、UI レベルでユーザーに視覚的なフィードバックを提供します。保存する前に、必要なすべてのプロパティがマネージャーで有効な値を持つことを検証できます。私はこれを 1 つのエンティティに 1 つのプロパティを使用して概念実証として考え出しましたが、それをアプリケーションの残りの部分に拡張する前に、もっと経験のある人がいるかどうか尋ねたいと思います。それが理由か、スケールアップするとなぜ気に入らないのか。これが悪いアイデアである場合、またはより良いアプローチを提案できる場合は、ご意見をお聞かせください。

Answer 1

これはかなり合理的な方法です (私も以前に似たようなことをしたことがあります) - しかし、 いつも 欠点:

• エンティティを必要とするコードには追加の参照が必要になります (属性とエンティティが異なるアセンブリにあると仮定します)。
• 値は (賢明でない限り) コンパイル時に決定する必要があります
• 自分の制御外のエンティティに対しては使用できません

ほとんどの場合、上記は問題ありません。もし彼らが は 問題がある場合は、外部メタデータ モデルをサポートする必要があるかもしれませんが、 ない限り それは必要です、これはやりすぎです。必要がない限り、それを行わないでください(意味:属性を使用してください。彼らです いつもの 大丈夫）。

Answer 2

カスタム属性を回避するためには固有の理由はありません。それは多くの利用可能な製品（コードコントラクト、FxCopの、など...）のバックボーンでサポートCLR機能です。

Answer 3

これは不合理なアプローチではなく、これを UI 層に組み込むよりも健全です。本格的なダイビングを始める前に、考慮する価値のあるポイントがいくつかあります。

• ビジネス ロジックとビジネス エンティティ自体を緊密に結合します。必須フィールドや有効な値が変更される可能性がある状況はありますか?自分自身を制限しているか、一貫性のない検証メカニズムに直面している可能性があります
• 動的割り当ては可能ですが、より注意が必要です。つまり、フィールドを必須に設定すると、オーバーライドしない限り、そのようになります。
• カスタム属性は、さらに複雑なことを実行したい場合、つまり属性駆動型の検証スキームに状態を​​渡す必要がある場合、非常に柔軟性に欠ける可能性があります。宣言的な代入のような属性。ただし、true/false の必須プロパティを持つことだけがここでは問題になりません。

悪魔の擁護者ですが、一般的に、必須フィールドのみを考慮するかなり単純なアプリケーションの場合、これは非常にきちんとした方法です。