別のMVCフレームワークを使用するためにSpring MVCアプリケーションをリファクタリングすることは可能ですか？

Question

私はちょうど春を使い始めており、現在はランプアップのためにSpring in Actionを読んでいます。 EJBの対春の利点を引用では、本は声明を出す：

「春で、成分は、典型的には、 、実装、拡張、または 任意の春固有のクラスや インタフェースを使用し、作るために必要とされていません可能性があります春の不在でも、コンポーネントをどこでも再利用することが可能です。

私のアプリケーションは現在Spring MVCを使用しています。依存性インジェクションを使用することにより、私たちのBeanはSpringフレームワークから完全に分離されているので、上記の記述がアプリケーションのビジネスロジックにどのように当てはまるかを見ることができます。しかし、この場合のWebアプリケーションは何ですか？私は、将来私のアプリケーションで別のMVCフレームワークを使用してSpring MVCをスワップすることが可能かどうか不思議です。

私の質問は二つです：
1）私はしっかりとSpringフレームワークに結合されたとして、Web層を見ると、私のMVCの変化がそれをサポートする新しいWebアプリケーションの作成を必要とすることを前提とすべきか？

2）そうでない場合は、WebアプリケーションとSpringのデカップリングにどのような影響がありますか？ Springフレームワークが存在しない場合、すべてのアノテーションをコントローラから削除する必要があり、関連付けられたコードを新しいMVCフレームワークをサポートするためにリファクタリングする必要があると私はすでに推測できます。

私はこのプロセスを経ている人の洞察に特に興味があります。

Answer 1

良い質問です。あなたが正しく指摘したように、MVCフレームワークは、ビジネスロジックレイヤよりもはるかに密接にSpring APIにコードを結合する傾向があります。

Spring 3よりもはるかに拡張されていませんが、アノテーションがコントローラに要求をマップするために非常に使用されています。メソッドのパラメータと戻り値のSpring APIへの結合は、大幅に削減されます。コントローラは、ビジネスロジックの観点から自分自身を表現することができます。

しかし、Spring MVCから何らかの表現力を得るためには、通常、そのAPIの使用が関与することになります。

あなたの質問に答えるには、Spring APIからコントローラコードへの結合は非常に少ないですが、そこにあり、削除する必要があります。しかし、それは非常に非侵襲的なAPIなので、コードに設計上の妥協がなく、別のフレームワークに容易に適応できます。ありがとう、それは役立ちます。