2

クライアント側のリッチインターフェースとサーバー側でJSONデータを返すSpringMVCには、スマートGWT、GWT、および関連するフレームワークを使用する予定です。

それが私たちの要件に適合するかどうかを確認するための調査の一環として、次の質問にはいくつかの回答が必要です。

  1. フレームワークを使用せずにGWTアプリケーションを最初から構築するには、標準のMVPパターンに従うためにかなりの労力が必要になります。ただし、これは時間がかかりますが、より柔軟でユニットテストが可能です。GWTのベストプラクティスは、より大きなアプリケーションを構築するためにMVPデザインパターンを使用することを提案しています。

SmartGWTには独自のアプローチがあり、ウィジェットを使用し、それにデータソースを導入すれば完了です。しかし、モジュール化された（またはMVP）方法でそのようなスマートGWTコンポーネントを構築することに関するベストプラクティスを特定すること。助言がありますか

  1. フレームワークGWTプラットフォームとSmartGWTを使用することは、ここで述べたようにMVPアーキテクチャを試すためのオプションである可能性があります。助言がありますか？

  2. スマートGWTの検証/メッセージ/例外表示およびその他の一般的な機能のサポートはまだ調査されていません。

  3. クライアントサーバーアーキテクチャ：サーバー側にSpring MVC + Springコア、クライアント側にGWT + Smart GWTを配置することは、オープンソーステクノロジーの優れたスタックになる可能性がありますが、GWTがデフォルトでクライアントサーバーの対話にRPCを使用することを考えると、これらのニーズの使用よりよく評価される。（特に認証/セッション処理/セキュリティなど）。助言がありますか？

ありがとう

4

3 に答える 3

2

私はSmartGWTまたはその他の豊富なライブラリを使用していませんでした。私の意見は偏っているかもしれませんが、Gwt コンポーネントはカスタマイズが容易で軽量であると本当に思います。これは、SmartGwt がそのタイプの他のライブラリーであるとは決して感じなかったものです。

そうは言っても、あなたの懸念の2つに対する私の答えは次のとおりです。

ここで述べたように、フレームワーク GWT-platform と SmartGWT を使用すると、MVP アーキテクチャを試すことができます。助言がありますか？

その点で MVP のようにとどまるには、プレゼンターからデータソースを設定するだけです。ビューでは、SmartGWT ウィジェットは「パッシブ」であり、プレゼンターからの構成を待機する必要があります。

利点: SmartGWT ウィジェットは既に十分にテストされているはずなので、ビューを単体テストする必要はありません。ビューを実際に呼び出す場所でプレゼンターをテストして、そのウィジェットを構成し、正しく呼び出すかどうかを確認するだけで済みます。

クライアント サーバー アーキテクチャ: Spring MVC + Spring コアをサーバー側に、GWT + Smart GWT をクライアント側に配置することは、オープン ソース テクノロジの優れたスタックになる可能性がありますが、GWT がデフォルトでクライアント サーバーの対話に RPC を使用することを考えると、これらのニーズの使用より良い評価を受けるために。（特に認証/セッション処理/セキュリティなど）。助言がありますか？

RPC はオプションであり、デフォルトの通信ではありません。RequestBuilder と RequestFactory の 2 種類の通信があります (DeRPC のような実験的な機能を試すとさらに多くの通信が可能になります)。

RequestBuilder は、JSON 応答で HTTP GET に使用できます。スマートな GWT アプローチの助けにはなりません。

これは Smart GWT を使用する Gwt-Platform のユーザーです。彼のブログを読んでください 。

この回答を書いている時点では、ブログはダウンしていましたが、すぐに再開されるはずです。

于 2011-02-28T14:52:39.383 に答える
0

私は現在、Smart GWT / GWT アプリケーションに取り組んでいます。

現在の Smart GWT についての私の意見では、多くの時間を節約でき、見栄えの良い便利なウィジェットがいくつか提供されます。とはいえ、これは JavaScript ライブラリのラッパーであるため、特にデバッグ時に注意が必要です。多くの場合、通常の GWT (または JavaScript ラッパーではないライブラリを使用した GWT) を使用する場合よりも、エラーを追跡するのがはるかに難しくなります。

あなたの質問にコメントしてみるには：

  1. この点で Smart GWT ライブラリが問題になることはありません。おそらく GWT が推奨する方法とは異なりますが、すべてのベスト プラクティスを突然放棄しなければならないという意味ではありません。

  2. これについて実際にコメントすることはできません-検証/メッセージ/例外ライブラリが問題であることがわかりませんでした

  3. クライアント/サーバー通信には JAX-RS を使用します。これは、Smart GWT がネイティブにサポートし、実装が非常に簡単です。XML 形式を使用しているため、おそらく GWT RPC よりもデバッグが簡単です。セキュリティにSpring Securityを使用しているだけで、ここでも問題はありません。

Smart GWT を再度使用することを再考する主な理由は、カスタマイズ可能性だと思います。たとえば、それらのフォームを使用する場合、レイアウトに関してあまり多くのことを行うことはできません。スマート GWT には独自の方法があり、独自のコンポーネントを作成する場合を除き、ほとんどその方法に縛られています (スマート GWT はスマート GWT とプレーン GWT コンポーネントの混合を推奨していないため、これは理想的ではありません)。

Smart GWT ライブラリを使用し、多くのカスタマイズを必要としないアプリケーションを喜んで作成する場合は、それで問題ありません。

于 2011-02-28T09:47:06.380 に答える
0

まず、MVP を使用する目的を検討する必要があります。

SmartGWT のサンプルに目を通すと、明確で最小限のコードが既に含まれていることがわかります。MVP を導入してサンプルを単純化または明確化することはできません。追加のコードと複雑さを追加することしかできません。

そのため、MVP を使用して追加のコードを導入したいという非常に具体的で具体的で説得力のある理由、つまり通常 SmartGWT を使用するだけでは達成できない特定の設計目標が必要です。

SmartGWT は非常に柔軟で、Selenium によるテストを既にサポートしており、さらに Selenium IDE 拡張機能と Selenium RC のサポートも備えているため、この種の有効な目標を見つけるのは非常に困難です。

MVP を追求する正当な理由として考えられるのは、2 つの完全に別個のビュー実装 (1 つは SmartGWT で、もう 1 つはプレーン GWT で単純化されたもの) を持つことです。あまり良い例ではなく、これを行う必要がある人を想像するのは難しいですが、それはまだ開発者が来ていないためであり、非常に漠然とした柔軟性の概念以外に、SmartGWT で MVP を使用する理由を明確に説明していません。

MVPを利用するのであれば、「Xをやる必要があり、SmartGWTを普通に使えば6ヶ月、MVPを追加すれば、 3」かかります。私の知る限り、そのようなシナリオを特定した人はいません。

于 2011-02-28T19:10:41.817 に答える