149

私たちは、カスタム開発されたMVCフレームワーク上に構築された大規模な Web サイトを、 Ajax、リッチ メディア コンテンツ、マッシュアップ、テンプレート ベースのレイアウト、検証、最大値の組み込みサポートを提供する Java ベースの Web フレームワークに移行する計画段階にあります。 HTML/Java コードの分離。

Grailsは良い選択のように見えましたが、スクリプト言語は使用したくありません。私たちはJavaを使い続けたいと思っています。テンプレートベースのレイアウトは、この Web アプリケーションを同様の機能を備えた複数の Web サイトで使用する予定であるため、主要な懸念事項ですが、ルック アンド フィールは根本的に異なります。

ポータルベースのソリューションは、この問題に適していますか?

「Spring Roo」または「Play」の使用に関する洞察は非常に役立ちます。

このような同様の投稿を見つけましたが、1 年以上前のものです。その間に状況は確実に変化しました！

素晴らしい答えをありがとう！このサイトは、最前線のプログラマー向けの最高の情報源になりつつあります。ただし、ポータル cms デュオの使用に関する詳細情報を期待していました。ジャヒアのルックスグッズ。似たようなものはありますか？

4

16 に答える 16

147

ポータルベースのソリューションはこの問題に適していますか？

個人的には、私は大きな太ったポータルソリューションから離れていました（それらはしばしば生産性を殺します）。Gateinについては良いことを聞いたことがありますが、実際の経験はありません。

「SpringRoo」または「Play」の使用に関する洞察は非常に役立ちます。

Spring Rooについては、 Spring roo Vs（Wicket and Spring）などの以前の回答をインターネットで読んだことがありますが、まだ確信が持てません（おそらく理解できません）。その成熟度はわかりません。そして、さらに重要なことに、SpringSourceがGrailsとRooで何をしているのか本当に疑問に思っています（いいえ、GrailsとRoo-なぜSpringSourceが2つの非常に類似したテクノロジーを推進しているのですか？両方が生き残るとは思えません）。

Playについてはあまり言えません。みんなと同じようにデモを見てきましたが、実際のフィードバックを読みたいと思います。それまでお待ちしております。

私は同様の投稿を見つけました（...）。その間に物事は確実に変化しました！

はい、いいえ:)しかし、プレゼンテーションフレームワークの地獄に入りましょう：あなたの質問に対する単一の答えはありません（1年前のように）、そこには数十のフレームワークがあり、明確な勝者はありません。いくつか引用するだけです：

  • JSF：私を含め、このコンポーネントベースのフレームワークについては多くの懐疑論者がいるので、私はそれについて話すのに最適な人ではありませんが...
  • JSF 2（+ CDI / Weld）：JSFの懐疑論者は、（Gavin Kingによって）「もう一度見てみる」ように勧められています。確かに、JSF 2は、特にCDIの場合、大きな改善だと思いますが、それでもかなり新しいものです（理解してください、フィードバックがありません）。Java EE 6を採用したい場合は、チェックしてください。
  • Wicket：注目を集めているもう1つのコンポーネントベースのフレームワーク。私はそれについて主に良いことを聞いています：JSFよりもシンプル、素晴らしいデザイン、高いテスト容易性、HTMLデザイナーフレンドリーなど。あなたはそれを好きかもしれません。
  • タペストリー：しないでください（タペストリーの使用をやめた理由を参照してください） 。
  • Struts 2、Spring MVC、Stripes：アクションベースのフレームワーク。すべてまともで、あなたのニーズをカバーします（個人的には、Stripesと設定より規約が好きです。それについては、 Stripes vs. Struts2を参照してください）。
  • GWT、Flex、Grails：これらはあなたが探しているものではないかもしれません。FlexとGWTの（最近のバージョン）については実際には話せませんが、Grailsにはファンがいることは知って います 。

実際、Matt Raibleのプレゼンテーションを見てみることをお勧めします。彼は、Webフレームワークの比較、長所と短所の表示、事実と数値の収集、傾向の表示で本当に素晴らしい仕事をしました...私はお勧めします：

本当に、これらのプレゼンテーションを見てください、それらはあなたが適切なフレームワークを見つけるのを助けます（ユニークな答えはありませんが、排除することによって選択を制限することができます）そしてあなたの視点を変えるかもしれません。

于 2010-01-18T07:36:25.487 に答える
41

Spring 3 3 と jQuery をしばらく使用していましたが、 Playについて聞いて試してみました。Play は、PHP のようなものと、Spring のようなヘビー デューティーな Java フレームワークとの間に最適です。

私が遊びで最も好きなことは次のとおりです。

  • Play アプリケーションを軌道に乗せるのは非常に簡単です。Spring を使用して単純なクラッド アプリケーションを画面に表示するには、コーディングと構成をかなり進めなければなりません (ただし、Spring 3 でははるかに簡単になりました)。
  • Spring Security は素晴らしいですが、複雑さが犠牲になります。Play のセキュリティ モジュールは非常にシンプルで、おそらく 90% のアプリケーションのニーズをカバーしています。
  • サーブレット ベースのフレームワークですべての再デプロイを行う代わりに、コードを変更してブラウザーで更新を押すと、PHP のように変更を確認できます。
  • エラー メッセージは適切に表示され、ほとんどの場合、わかりにくいものではありません。Play はまだエラー処理に取り組む必要があります
  • Play には非常にシンプルなプラグイン メカニズムがあります。
  • オブジェクトの永続化は、メモリ内データベースとJPAがフレームワークに付属しているため、外部オブジェクトの永続化ツールの構成がないという点で非常にうまく行われます。インメモリ データベースから実際の RDBMS に移行するには、構成ファイルを 1 行変更します。
  • MVC のセットアップは非常にうまく行われています。ドメイン オブジェクトを作成するために拡張する Model クラスは、JPA エンティティ マネージャーと統合されます。それらは単なるPOJOではありません。
  • コントローラへの URL のマッピングはシンプルかつ柔軟で、すべてが 1 つの「ルート」ファイルに含まれています。
  • プロジェクトを作成するときはいつでも、Play はすべての JAR 依存関係を処理し、Play にはプロジェクトをEclipse化 (または好きな IDE) するユーティリティがあり、お気に入りの IDE に直接インポートできます。

Play の嫌いなところ

  • ドキュメントはまだ完成していません。ドキュメントに記載されていない機能がまだたくさんあります。
  • フレームワークはサーバーであるため、各アプリケーションに専用のポートを割り当てる必要があります。誰かが仮想ホスト プラグインに取り組んでいると思いますが、まだ実際に動いているのを見たことがありません。
  • それは若く、プロジェクトは素晴らしく、技術も素晴らしいですが、本当にもっと多くの開発者が必要です. しばらく時間を割いてみたいと思います。
于 2010-07-29T16:39:52.037 に答える
17

私にとって一番の選択はWicketです。

それは持っています：

  • マークアップと Java コードの明確な分離。
  • コンポーネントの作成と使用は非常に簡単です。
  • 使いやすい Ajax
  • テスト容易性。

ページ/コンポーネントを直接デバッグでき、JSF実装から不可解なエラー メッセージが表示されることはありません ;)

性能面ではウィケット<-->JSFとの比較も良い。

于 2010-01-18T09:26:53.210 に答える
11

PlayはRubyonRails （Javaのhttps://en.wikipedia.org/wiki/Ruby_on_Railsバージョン）とよく似ています。

于 2010-01-18T07:59:11.930 に答える
10

他の回答とは対照的に、人気のあるWebフレームワークの欠点（IMHO）を強調したいと思います。

JSF 2-リリースされ、すでにエージングされています。まだいくつかのニュース/記事/ブログ投稿/経験があります。私は懐疑的です。JSF2を完全にサポートするRichfaces/Icefacesの次のメジャーリリースをまだ待っています-現在、ダウンロードできるのはアルファビルドのみです。

Struts 2-まだStrutsに依存していて、コードの大部分をリファクタリングしたい場合にのみ、良いことのようです。それ以外の場合：しないでください。

GWT-私はシングルページとJava→JavaScriptのアプローチが好きではありません。1つのセッション（複数のビュー/ウィンドウを簡単に実現できるかどうか）がわかりません。私にとって、このフレームワークは、大規模ユーザーのシングルウィンドウリッチインターネットアプリケーションに使用する必要があります。

ウィケット-優れたアプローチですが、少し冗長で、利用できるドキュメントが少なすぎます（アクションブックの優れたウィケットを除きますが、これは1.3しかカバーしていません）。また、私にとっては、その上に構築された大きなプロジェクトが不足しています。そして、私は現在、改札の道がどこを進んでいるのか、あるいはそれがすでに行き止まりに追いやられているのかどうかを知ることができません。

Spring MVC-私はまだこれを試していませんが、このフレームワークを正しく機能させるには、クラスパスに多くのJARファイル（Spring mess）を含める必要があります。そして、それは（ほとんどのプロジェクトで） JSPに依存していますが、これはすでに死んでいると私は考えています。そして、純粋なMVCフレームワークのみを取得します。他のすべてのもの（ Ajaxなど）を実装/統合する必要があります。

ストライプ-小さくて素敵な設計のMVCフレームワークですが、ドキュメントが少なすぎ、コミット/コミッターが少なすぎ、リリースが少なすぎ、業界のサポートが少なすぎ、メーリングリストのアクティビティが少なすぎます。

そこにある主要なフレームワークを見逃したかどうか（タペストリーを意図的に除外した）も気になります。これはあなたにとって（そして私にとっても）選択肢になるかもしれません。

于 2010-06-16T08:53:11.967 に答える
8

私はJAX-RSで大きな成功を収めました。これは、ある種のJSR仕様と、サーブレットおよびポートレット仕様以外の複数の実装を持つ唯一の Java Web フレームワークです (これは悪いことかもしれませんが)。

Java の良い点と悪い点の 1 つは、フレームワークを選択して一致させることができることです (Python にもこの機能/問題があります)。すべての卵を 1 つのバスケットに入れる必要がないので便利です。

一般的な Java Web アプリケーション スタックのレシピを次に示します。

JavaScript/Flash + リクエスト/レスポンス処理 + 依存性注入 + 永続性

JavaScript: jQuery、プロトタイプ、道場

リクエスト/レスポンス: Spring MVC、Stripes、そしてお気に入りの JAX-RS (Jersey、Apache CXF)

依存性注入: Spring、Guice

永続性: JPA ( Hibernate、Google アプリ ストレージ)、Hibernate、JDOなど。

私はまた、 AspectJを使用して Java を「サックレス」にすることに大きな成功を収めました。Spring の @Configurable と AspectJ の ITD mixin を使用すると、Ruby on Railsのようなドメインオブジェクトを取得できます (これは実際に Roo が行うことですが、これを行うために Roo は必要ありません)。

于 2010-11-30T19:44:43.933 に答える
6

Stripesは非常に効果的で、驚くほど軽量であることがわかりました... Strutsよりも軽量化を目指しています。

フルタイムの Web 開発者である友人から、 JSFを気にする価値はないという話を聞いたことがあります。

于 2010-01-18T09:47:30.443 に答える
5

Play !と同じ原則に従うRESThubをご覧ください。ただし、 Maven 3、Spring Framework 3、Jersey、jQuery などのエンタープライズ グレードのフレームワーク/ツールを再利用して実装されています。

RESThub はフルスタックのツールキットであるため、他のフレームワークと比較して非常に破壊的ですが、サーバー側の MVC またはサーブレット ベースのフレームワークはありません。代わりに、JAX-RS ( REST ) Web サービスを使用するjQuery UIベースの GUIと、embeddedJs に基づく JavaScript テンプレート システムを使用します。

サーバーはステートレスであり、クライアント側でセッションを維持するために HTML5 sessionStorage を使用します。このアプローチは、RIAとスケーラビリティを考慮して設計されています。

一部のデモ アプリケーションが提供されています (作成中であっても)。

于 2010-05-18T12:51:11.657 に答える
3

JSFは優れたフレームワークですが、JSF 1.2は、リリースから何年もの間ビジョンを欠いていました。JSF 2.0は有望に見え、JSF 1.2から追加された多くの新しい機能があります。たとえば、 Ajaxサポート、フェイスレット、アノテーションサポート、デフォルトの規則（XMLが少ない）、1.2よりも簡単なコンポーネント構築などです。

DIのサポートが必要な場合は、Springともうまく統合できます。

于 2010-01-18T07:26:17.277 に答える
2

私はVaadinに言及する必要があります。

プログラミングは、コンポーネントベースのアプローチを使用して、Javaでのみ実行されます。クライアント/サーバー通信は、データ転送よりもユーザーインタラクションに関するものであり、すべてのビジネスロジックはサーバー上にあります。

于 2011-07-23T07:51:42.910 に答える
2

私は春の推薦を支持します。私はGWTの大ファンというわけではなく、Java から JavaScript へのクロスコンパイラーがまだ完成しているとは思いません。

私は、サーバーで Spring を使用し、クライアントで jQuery を使用するAjaxアプリケーションに取り組んでいます。技術的には jQuery の「すぐに使える」サポートはありませんが、Spring-MVC AjaxView の実装は非常に簡単で、約 25 行のコードが必要です。

于 2010-01-18T06:10:48.677 に答える
1

ItsNatを見てください。

ItsNatは、基本的にサーバー内のJava W3Cブラウザーであり、驚くほどシンプルで（サーバー内のDHTML）、Ajaxを多用するシングルページインターフェイスアプリケーションを促進します。

于 2010-11-04T08:28:25.257 に答える
1

バックベース ポータル ソフトウェア

数年前、私はポータル ソフトウェア「Backbase」を使用していましたが、これはあまり成熟していませんでした。

しかし、開発は簡単で良かったです。

于 2010-07-29T16:46:21.887 に答える
1

あなたが探しているのはJahiaに近いものだと思います。GWT、マッシュアップ、メディア コンテンツなどをサポートします。

http://www.jahia.org/cms/lang/en/home/Jahiapedia/Jahia_Templates

http://www.jahia.net/downloads/jahia/jahia6.0.0/readme/index.html

于 2010-01-18T10:17:18.157 に答える