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

Question

これは主に、私がこの道をたどってはいけない理由がある場合のコメントのリクエストです.

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

Answer 1

それを行うのはかなり合理的な方法です（私は以前に非常に似たようなことをしました）-しかし、常に欠点があります：

• エンティティを必要とするコードには、追加の参照が必要になります (属性とエンティティが異なるアセンブリにあると仮定します)。
• 値は（あなたがそれについて賢くない限り）コンパイル時に決定する必要があります
• コントロール外のエンティティには使用できません

ほとんどの場合、上記は問題になりません。それらが問題である場合は、外部メタデータ モデルをサポートすることをお勧めしますが、必要でない限り、これはやり過ぎです。必要でない限り、これを行わないでください (つまり、先に進んで属性を使用してください。通常は問題ありません)。

Answer 2

カスタム属性を避ける固有の理由はありません。これは、利用可能な多くの製品 (コード コントラクト、FxCop など) のバックボーンである、サポートされている CLR 機能です。

Answer 3

これは不合理なアプローチではなく、このようなものをUI層に焼き付けるよりも健康的です。フルダイブを行う前に検討する価値のあるポイントがいくつかあります。

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

悪魔の擁護者であるだけで、一般的に、必要なフィールドだけを気にする非常に単純なアプリケーションの場合、これは非常に整然とした方法です。