2012-01-21 8 views
1

私は、Spring MVCのアノテーション駆動型モデルが便利だと言わなければならないが、フレックスの世界から来ているので、私はコマンド設計パターンの使用に慣れている。抽象化のレベルを減らし、汎用コマンド機能を拡張することにより柔軟性を実現するのは非常に簡単です。しかし、私はこれをSpring環境に適合させることは困難です。理想的な場合に Spring MVCアノテーション駆動クラスと純粋なコマンドの比較

は、何コントローラが、リクエストパラメータに基づいて(またはURLパスはvarsの)、1つの汎用HandleWebRequestCommandクラスは、別のコマンド(またはコマンドの鎖)を実行するがあってはなりません。他のコマンドは、リモートサービスの呼び出し、DB検索/永続性の処理、ファイル操作などを担当します。これにより、Controller/Service/Persistenceケーキ全体が交換可能なコマンドと非結合コマンドのセットになります。

最も難しい部分は、現在起こっていることと実行されるべきコマンドとの間のマッピングを作成しているようです。私はすべてのコマンドが宣言されているこの目的に非常に適したXMLコンテキストのようなファイルを参照しています。また、それらの依存関係が提供されます(すべてのコマンドには、それが依存する他のコマンドのセットがあるかもしれません)。これまでは、イベントドリブンアーキテクチャの使用を想定していませんでした。 HTTPリクエストの結果として実行されるので、最も重要なマッピングはHandleWebRequestCommand内のものになります

私は混乱します。助けてください。私はこの春にふさわしいか、Java EEの上に自分自身のアーキテクチャを直接開発していくべきでしょうか?そのような建築はまったく問題ないのですか?

答えて

4

私はあなたがまだそれが何であるかについて春を見ていないと思います。

"一般的なHandleWebRequestCommandクラス"は既に存在しています。つまり、物事がコントローラにルーティングされる方法です。 「コマンド」は(大まかに)サービスであり、いくつかの方法で作成して組み合わせることができます。

春が大部分で、物事を正確に切り離すために、それはかなり良いです。


あなたはより具体的な援助をしたい場合は、おそらく人々は、他の1つのパラダイムからマッピングすることができ、あなたは春のようにきれいに行うことができない何を考えての簡潔な例を掲載したいと思います。

+0

コマンド!=サービス。コマンドははるかにきめ細かく、懸念を横断することができます。厳密な1回実行法の設計パターンに従うので、パターンを簡単に切り替えることができます。 – preslavrachev

+1

@ user1107412あなたは人工的な区別をしています。サービスは、あなたが望むものであれば何でも構いません。 –

+0

@ user1107412結論は、あなたが望むものを何でも好きなものに注入でき、好きなものを呼び出すことができ、それぞれが大規模から小規模のあらゆる操作を実行できることです。 –

関連する問題