過去に、エンティティのダーティ チェックを行うためにいくつかの異なる方法を使用してきました。私は、新しいプロジェクトでこれを達成するために AOP を使用するというアイデアを楽しんでいます。これには、プロパティが設定されているときにダーティ フラグ ロジックを呼び出したいクラスのすべてのプロパティに属性を追加する必要があります。属性の各プロパティに余分なコード行を追加する必要がある場合、セッターで SetDirty() メソッドを呼び出すだけの利点は何ですか。私は、AOP アプローチを使用する利点があるとすれば、それが何であるかを尋ねていると思いますか?
1157 次
6 に答える
2
この場合、利点がないだけでなく、少し欠点があります。dirty()呼び出すか AOP を使用するかに関係なく、同じ数のコード行を使用していますdirty()が、意図する限り、呼び出しはより単純で明確です。
正直なところ、AOP は少し売られ過ぎだと思います。コードを読むという点で、別のレベルの間接性が追加されますが、それはしばしば報われません。
ここで考えるべき重要なことは、これを読んでいる次の人 (数か月後のあなたかもしれません) が、私がやろうとしていることをより迅速かつ明確に理解するのに役立つかどうかです。あまり単純ではないアプローチの何が優れているかを理解するのに苦労している場合は、おそらくそれを使用しない方がよいでしょう。(そして、私はこれを Haskell プログラマーとして言います。つまり、私自身、単純明快でないアプローチに反対しているわけではありません。)
于 2009-05-22T13:29:53.897 に答える
0
ダーティチェックをエンティティの責任にしたいのはなぜですか? これは別の場所で管理できます。このパターンはUnit of workと呼ばれます
于 2009-05-22T18:00:33.900 に答える
0
一部の AOP 実装、特に PostSharp では、どのクラスに適用するかについて、ワイルドカードを使用してアセンブリ レベルで属性を適用できます。
于 2009-05-22T13:35:50.560 に答える
0
SetDirty利点は、ダーティ フラグ ロジックを呼び出す方法の実装を変更することにした場合、N 個の変更 (すべての呼び出しを別のものに置き換える) ではなく、(AOP メソッドの本体で) 1 つの変更を加えるだけでよいことです。
于 2009-05-22T13:16:11.507 に答える
0
エンティティを属性で装飾する必要がある場合、何のメリットもありません。特に、単一のメソッドを呼び出すだけの場合。ロジックがより複雑であれば、AOP を使用するための議論を行うことができます。
プロパティを変更するたびにその変更をバージョンとして追跡したい場合、これは注入できるより複雑な動作である可能性があり、これをプロパティから抽象化することは有益です。同じ時点で、おそらく一度に複数のプロパティをバージョン変更する必要があるため、あまり価値がないことに戻ります。
于 2009-05-22T13:16:54.827 に答える
0
AOP の使用は、横断的な関心事のためです。これは、ロギング、セキュリティなどの機能が必要であるが、ビジネス ロジックが実際にはクラスに属していないことを意味します。これは、ドメイン オブジェクトが変更されたことを気にする必要がないため、ダーティ フラグ ロジックのためである可能性があります。それはあなたの DirtyLogicUtility またはそれが持っている名前次第です。
たとえば、メソッドが呼び出されるたびにログを記録したい場合は、これをすべての関数に配置できますが、後で他のすべての呼び出しでログが記録されるようにロジックが必要です。
AOP は、他の部分をそのままにして、クラスが本来行うべきことを実行してクラスをクリーンに保ちます。
于 2009-05-22T13:24:42.703 に答える