19

Spring rooは新しいフレームワークであり、非常に興味深いものでした。私は過去3〜4年間Webアプリケーションに取り組んできましたが、マークアップとサーバーサイドロジックの分離について全員が十分に訓練されていないと、チーム間でJSPを維持するのが難しいことが常にわかりました。私は前回のプロジェクトでJackBe/BackBaseを使用し、ビューとして機能するxmlテンプレートを楽しんでいました。これはJSPよりもはるかに優れていました。しかし、バックベース用のセレンを介してWebテストを自動化することはできませんでした。

確かに、バックエンドでHibernateのSpring MVC（-view）を使用します。Wicketが良い代替手段だと思いました。春と一緒に改札を使ったことはありますか？また、どのような経験をしましたか？

4

9 に答える 9

16

まず、Spring Roo はコード生成ツールです ( Grails コマンドシステムに似ています)。

代替テキスト
(出典: springsource.com )

次に、Spring Roo アプリケーションは現在、ビューに Spring Web Flow を使用し、グルーに Spring を使用しています。

したがって、(Spring Web Flow + Spring) と (Wicket + Spring) を比較することはできますが、後者のコンボはすぐに使用できる Roo に匹敵するものを提供しません ( AppFuseまたはAppFuse Lightかもしれませんが、言及していませんでした。サードパーティのプロジェクトです)。

つまり、「Spring Roo vs (Wicket and Spring)」は意味をなさないと思います。

于 2010-01-24T09:07:42.727 に答える
14

現在のプロジェクトでは Spring と Wicket を使用しています。これまでずっと Spring を使用していましたが、1 年前に Wicket に切り替えました。いくつかのアドバイス:

  • 「Wicket in Action」の本を入手してください。
  • ユーザーメーリングリストはとても役に立ちます。
  • Wicket のプログラミング モデル、特にセッションのシリアライゼーション関連のものを理解していることを確認してください (この分野では、この本は十分に役に立ちません)。
  • Wicket はステートフルなページを構築するのが得意ですが、ステートレスなページを構築するにはより多くの作業が必要です。
  • Inmethod DataGrid のように、いくつかの優れた UI ウィジェットが利用できます。
  • ページまたはコンポーネントに Spring Bean を挿入するのは簡単です。

Spring Roo はまだベータ版 (1.0 M2) であるため、少し早いかもしれません。タペストリー5も検討しましたが、1年前は少し若いと思っていました。

于 2009-07-15T05:03:45.993 に答える
8

Spring Roo 1.0.0 (GA) がリリースされ、約 100 ページのドキュメントが完成しました。

Roo とは何か、また Roo を使用する理由について疑問に思っている場合は、リファレンス ガイドの導入部の章を読むことをお勧めします。それはこれとそれ以上をカバーしています。

@Antony、GWTのサポートは Roo の主要な優先事項であり、私が現在取り組んでいるものです。近い将来、興味深い統合が見られることを期待してください。

于 2010-01-08T21:06:59.120 に答える
4

Roo が発表されたとき、私は今年初めにアムステルダムで開催された SpringOne カンファレンスにいました。私の印象 (およびそこにいた私の同僚の印象) は、Web ベースの CRUD アプリケーションを数週間ごとに生成する場合、Roo は優れているというものでした。Roo は、Grails の純粋な Java バージョン (Java の RoR) として売り込みました。

他の人にとっては面白くありませんでしたが、それは単なる意見です.

于 2009-07-20T07:25:56.620 に答える
2

数か月前に Roo のデモを見たことがあります。これは Grails (別の Spring テクノロジー) によく似ていますが、Groovy 言語用の成果物を作成する代わりに Java 用に作成する点が異なります。
それでも、それは良い習慣を強制し、MVC パターンをクリーンな方法で適用させます。

個人的には、このデモでは好みのツールキット (Grails) を変更する必要はありませんでしたが、それは Groovy を使用した方がより高速な結果が得られるためです (たとえば、xml の解析は、Groovy よりも Java の方がはるかに「苦痛」です)。また、Grails を使用すると、結果を確認するたびにプロジェクト全体を再コンパイルしてアプリケーションを再起動することなく、行った変更をすぐに確認できます。最後になりましたが、Grails には凝った Ajax Web サイトを作成するためのプラグインがたくさんあります (たとえば、Javascript を避けたい場合は ZK ですが、GWT、Yahoo、Dojo などのプラグインがあります...)。

したがって、Groovy を学びたくない場合 (既に Java を知っていればそれほど難しくありません)、Roo は Hibernate と Spring のすべての機能を備えたクリーンな Web プロジェクトを構築するための方法です。

これが役立つことを願っています...

于 2010-01-24T07:28:30.817 に答える
2

Roo とそのアーキテクチャーの制約を受けずに、GWT を使用して何かを構築し、はるかに優れた結果を得ることができるのに、なぜ Roo を使用するのでしょうか。Spring Web Flow は昨日のテクノロジーです。

于 2010-07-28T02:21:58.950 に答える
1

それはあなたの要件が何であるかに完全に依存します。小さなサイトの場合、GWT や Wicket などのコンポーネント指向のフレームワークは必要不可欠です。

于 2009-07-18T07:20:58.427 に答える
0

Roo は GWT をどのくらいサポートしますか? Roo による GWT の使用は、GWT と Roo にとって大きな勝利になると思います!

于 2010-01-24T07:14:16.663 に答える
0

Roo と GWT は現在、プレリリース形式で入手できます。私の意見では、間違いなくゴールデンタイムの準備ができていません。

于 2010-06-12T00:11:22.183 に答える