7

この質問は以前にもあったことは知っていますが、これは 1 年半前のことですが、再質問の時期かもしれないと思いました。主観的と思われるかもしれないことも認識しましたが、AOP には賛成/反対の客観的な理由があると思います。

誰がソフトウェア開発でAOPを使用しているのか、また、なぜ使用しないのか、または使用しないのかについても興味があります。

AOP は、多くの開発作業を容易にする非常に強力なパラダイムであると私は考えています。しかし、実際のプロジェクトで AOP を使用することになると、多くの意思決定者がほとんどオープンになっていないという経験をしました。どのようにして AOP をプロジェクトに導入しましたか?

2008 年 8 月の以前の質問:プロダクション ソフトウェアで AOP (アスペクト指向プログラミング) を使用していますか?

4

3 に答える 3

1

AOP 自体を 100% 使用するわけではありませんが、必要に応じていつでも使用します (主に Spring AOP。これは Spring フレームワークとうまく統合されています)。

どのようにして AOP をプロジェクトに導入しましたか?

まあ、横断的な懸念を分けてください。メソッド呼び出しのトレース。Spring AOP では、コードの「フックされた」セクションに適用されるアスペクト (ランタイム動作) を定義できます。「フック」とは、この動作が必要なすべてのメソッドを 1 つの共通の傘の下にグループ化できることを意味します。実行時に、この統合されたコードは、アスペクトによって定義された新しい動作を取得します。

于 2010-01-28T16:19:19.853 に答える
1

当社のマネージャーは、建築チームの意見に耳を傾けます。

AOP がクロスコンサーン機能を実装する唯一のソリューションであると伝えます。

  • そもそも妥当な費用で
  • 開発チームによって書かれた機能コードをいじることなく
  • (数千のメソッドに手動で try-catch を追加する場合と比較して) 現在も将来も忘れることなく
  • 開発者が何をしているかを訓練したり制御したりする必要はありません (素晴らしいものもあれば、本当に混乱しているものもあります)。
  • メンテナンス性が良い

確かに、私たちのプロジェクトは 20 人の開発者で、数年間続いたので、大量のコードがあります。それが唯一の解決策です。

重要なのは、分野横断的な関心事にのみ使用することだと思います。通常のコードを使用してコーディングできる場合は、そうしてください。しかし、大きすぎる場合、AOP は魅力的で正当化されます。AOP の制限に失敗すると、何百もの AOP の小さなコードが発生し、理解するのが非常に困難になります。

はい、私たちのソフトウェアはプロダクション ソフトウェアです。何百もの診療所がそれに依存しています！

于 2010-01-28T16:20:56.573 に答える
0

プロジェクトでSpringフレームワークをすでに使用している場合は、Peakitが述べたようにSpringAOPを簡単に導入できます。

私は最初に、内部でのみ使用され、顧客にリリースされることのないツールプロジェクトにAspectJを追加しました。これにより、開発チームと管理者の両方がツールに自信を持ち、ツールで何ができるかについて明確なアイデアを得ることができました。

于 2010-01-28T16:45:06.793 に答える