5

私の同僚の何人かは、横断的関心事の例として検証を考えており、アスペクト指向プログラミングが検証の懸念を処理するための良い方法であると考えています。PostSharp表記を使用するには、次のようなものが良い考えだと彼らは考えています。

[InRange(20.0, 80.0)]
public double Weight
{
    get { return this.weight; }
    set { this.weight = value; }
}

私の意見では、検証はアルゴリズムの本質的な部分であり、AOPを使用して舞台裏でそれをプッシュする必要はありません。しかし、それは腸の感覚によく似ており、私にはそれを正当化する明確な理由がありません。

いつAOPで検証を処理するのが良いと思いますか、そしていつメインコードとインラインで処理するのが良いと思いますか？

4

2 に答える 2

2

MVC で使用されるMicrosoft DataAnnotationsによく似ています。

関連するすべての情報が属性コンストラクターにあるため、実際には「舞台裏でそれをプッシュ」しているわけではありません。騒々しいボイラープレートを舞台裏で独自のクラスに押し込んでいるだけです。また、明示的なバッキング フィールドも不要になり、自動ゲッターとセッターのみを使用できます。これで、8 行 (またはそれ以上) のコードを 1 行と 1 つの属性に減らすことができます。

あなたの代替手段がセッターの中にいくつかの検証コードを入れることであり、プロジェクトで繰り返しボイラープレートになるまでそれを複数回行う場合、はい、それは有効な横断的懸念であり、PostSharp を使用するのに適していると思います. そうでなければ、まだサードパーティのツールを持ち込むことを正当化する場所が 1 つまたは 2 つあるとは思えません。

于 2012-05-10T14:48:20.710 に答える
0

特にAOPで実装したことはありませんが、横断的関心事だと思います。

とはいえ、さまざまな検証シナリオがあり、それらがすべて正確に黒または白になるとは思えません。

Microsoftのパターンと実践-横断的関心事

于 2012-05-09T22:18:59.603 に答える