Spring MVC（または他の同様のフレームワーク）をGWT RPC用のサーバとして使用する理由はありますか？私が知る限り、99.9％のSpringの機能は使用されません。しかし、多くの人々が、それらを一緒に使う最善の方法を模索しています。GWTとSpring MVC、それだけの価値はありますか？
誰かがGWTでMVCフレームワーク（サーバー上）を使用する利点は何か、説明してください。サーバー側で必要なのはビジネスロジックですか？
Spring MVCや他のエンタープライズJava MVCライブラリ（Strutsなど）を、あなたが言ったように（つまり、ビジネスロジックのみを提供するレイヤーと共に）使用することは、可能な限りきれいに）。
しかし、Spring自体は単なるWeb（MVC）フレームワークレイヤー以上のものであり、依存性注入やAOP機能、ORM APIやScripting言語Groovy（Springとうまく機能する）を使用することは、応用。
依存性注入は、異なるライブラリを使用して行うことができます。例えば、軽量Guice。 AOPを使用したことがないので、かっこいいかどうかわかりません。 ORM ...はい、私はそれを忘れていました。いい点があるかもしれません。 – bezmax
GWTアプリケーションがサーバーにRPC呼び出しを行う必要がある場合、MVCレイヤーは依然として関連しています。 – skaffman
どのように古典的なMVCを適切に含めることができないのか分かりません。ビューは、データの表現（XMLまたはJSON）に過ぎないので、HTML/JSP/Taglibの全要素を実際には必要としません。もちろん、モデルとコントローラの分離はまだ存在するはずです。 – Daff
Springは単なるMVC以上のものです。
GWTでUIを操作しても、何らかのバックエンドロジックが必要です。 データベース、トランザクション、セキュリティ、追加サービスの統合（電子メール？SOAP？）などがあります。
このSpringまたは他のJavaサーバー側のテクノロジは、良い解決策になります。
ダフが言ったように、SpringはDI + AOP +トランザクション+多くのものをもたらします... Springでサーバー側で管理されているものを持つと便利です。
さらに、ライブラリgwtrpc-springは、POJOSを@Serviceアノテーションとともにrpcサービスとして宣言するための非常に便利な方法を提供します。 @Serviceを持つクラスのスキャンが自動であるため、web.xml内の各rpcサーブレットの宣言を避けます。
GWTは単なるツールキットであり、フレームワークではありません。あなたのデベロッパーがSpringを簡単に利用できる場合は、それを使用してください。
私はクライアント側のGWT + GINとサーバー側のGuiceに行く傾向があります。 しかし、Springは永続性、トランザクション、サーバー側のビジネスロジックの整理に使用できます。
「99.9％のSpringの機能は使用されません」...地球上ではどのような印象を与えましたか？ – skaffman
まあ、私はそれがすべての用途を見ていないと思う。私がSpringを使って作業したのは、MVCのアプローチの方法が異なっていたからです。 – bezmax
十分ですが、MVCよりSpringには*ロット*が多くあります。 – skaffman