Spring MVCのドキュメントを見ていましたが、コントローラーがインターフェイスを実装し、プロキシされた場合、ターゲットクラスごとにインターフェイスまたはプロキシにアノテーションを配置する必要があるという言及がありました。そうしないと、アノテーションが取得されません（コントローラクラスのサブクラスでない場合は、公開されたインターフェイスを介してBeanをラップする別のクラスになるため、プロキシにはアノテーションが含まれません。
ただし、私の経験では、コントローラーは最も単純なものであると考えられています。Webベースの入力を取得し（「モデル」のフォーマット/作成）、ビジネスサービスレイヤーのインターフェイス/クラスに委任して実行するフロー制御を決定します（制御モデルの状態に基づいて）、モデルをビューレイヤーに送信して、結果のビューを作成します。
コントローラーをプロキシしたい理由の本当に良いユースケースを誰かが提供できますか？サービスレイヤーメソッド、確かに、しかしコントローラー？
コントローラーをプロキシする理由は、Proxy AOPを実行するためです。
プロキシ AOPは、プロキシ インターフェイスのみを実行する動的プロキシでのみ機能していました。ただし、Spring は CGLIB プロキシをサポートするようになったと思います。
個人的には、Spring もサポートする実際のコンパイル時の AspectJ を使用して、プロキシ ベースの AOP を完全に回避しています。
なぜコントローラを AOP にしたいのですか? セキュリティ、入力サニタイズ、ロギングなどのボイラープレート コードを避けるため (これらはすべて、リクエスト コントローラーで行います)。
編集：フォローアップがあることを知っていたので、昨夜この回答を補足するつもりでした。
はい、今日のリクエストでは、サーブレット フィルターとインターセプターを使用して多くの AOP を実行できます。また、フィルターにクロス カット コードの大部分があります。AnnotationMethodHandler > 3.0 (setter を介した追加の戦略コンポーネントの過多に注意してください)。
AOP を使用する理由の実際の現在の@PreAuthorize例は、XML ファイルにインターセプターを配置する代わりに、要求コントローラーで Springs Security Annotations (つまり) を使用することです (この質問と私の回答を参照してください)。あるいは、サービス レイヤーが不要で、@Transaction.
コントローラーで AOP を使用するもう 1 つの理由は、より宣言的であり、メソッドを直接呼び出して単体テストを行うときに機能することです (ただし、プロキシではなく AspectJ を使用します)。実際、私は Python の Decorator に似た AspectJ を使用して、定型コードでメソッドを宣言的にラップしています。フィルターはあなたが注釈を付けたものを知らないので、そこでこのロジックを実行することはできません。
最後に、小規模な Web アプリケーションや REST のみのアプリケーションでは、サービス層を追加することは過大評価されており、アクティブなレコード/DAO とコントローラーで十分であると考える人もいます (Spring Roo を参照してください...最近サービス層が追加されたばかりです)。その場合、前述のよう@Transactionに、コントローラーでのサポートが必要になることがよくあります。
そうでなければ、最新の Java (および/または AspectJ) の適切な使用例は実際にはありません。IMHO私はもう動的プロキシを使用していません。