最近、アノテーションをサポートする Spring MVC 3.1 を見ていて、今後のプロジェクトの DDD も検討していたので、(タイトルに記載されているように) 質問が私に来ました。新しいSpringでは、ビジネスメソッドを持つPOJOに注釈を付けてコントローラーとして機能させることができます。コントローラークラス内で対処したであろうすべての問題は、注釈を介して排他的に表現できます。
したがって、技術的には、任意のクラスを取り、それを配線してコントローラーとして機能させることができます。Java コードはコントローラー固有のコードから解放されているため、Java コードはセキュリティのチェック、txn の開始などを処理できます。そのようなクラスはに属しますプレゼンテーション層またはアプリケーション層 ??
その議論をさらに進めると、セキュリティや txn mgmt などを引き出してアノテーションで表現できるため、Java コードはドメイン オブジェクトのコードになります。これは、2 つのレイヤーが融合したことを意味しますか? どうか明らかにしてください
AOPに関して、質問のタイトルに近づきます：
AOP は「レイヤード アーキテクチャ」に違反していません。具体的には、定義上、機能が使用されているレイヤーに関係なく、アプリケーション全体の機能を追加しているためです。正規の AOP の例は、ロギングです: レイヤーではなく、機能です。すべてのレイヤーはロギング。
AOP を質問に結びつけるには、Spring の AOP メカニズムを介して処理できるトランザクション管理を検討してください。「トランザクション」自体はどのレイヤーにも固有ではありませんが、特定のアプリは単一のレイヤーでのみトランザクションを必要とする場合があります。その場合、AOP は単一のレイヤーにのみ適用されるため、レイヤード アーキテクチャに違反しません。
トランザクションがレイヤーをまたがる可能性のあるアプリケーションでは、トランザクションが存在する場所は実際には関係ないため、レイヤー化の原則にまだ違反していません。重要なのは、「この機能のチャンクはトランザクションでなければならない」ということだけです。そのトランザクションが複数のアプリの境界にまたがっている場合でも。
実際、このような場合に AOP を使用するとレイヤーが明確に保持されると言えます。TX コードがこれらすべてのレイヤーで機械的に再現されるわけではなく、単一のレイヤーが (a) トランザクション コンテキストで呼び出されているかどうかを疑問に思う必要がないためです。 、または (b)どのトランザクション コンテキストにあるか。
POJO を取得してコントローラーにすることはできません。コントローラーの仕事は、ブラウザーから入力を取得し、サービスを呼び出し、ビュー用にモデルを準備し、ディスパッチ先のビューを返すことです。まだコントローラーです。XML とメソッドのオーバーライドを使用して構成する代わりに、注釈を使用して構成します。それだけです。
このコードは、コントローラー固有のコードから自由になるにはほど遠いものです。ModelAndView、BindingResult などを引き続き使用します。