10

私はJavaWebアプリケーション開発者として、昨年JSF（SUN）をWebアプリケーションのフレームワークに使用しました。私はそれを使うのがとても好きだったと言わなければなりません、それは開発をより簡単にします。

最近、JBoss Seamについて多くの良いことを読みましたが、それを使用した人にはまだ会っていません。私が読んだことから、SEAMはJSFの次のステップのようです。

したがって、私の質問は、SEAMを使用したことのあるあなたにとってです。このテクノロジーを使用しているときに、不利な点に遭遇しましたか？それを使って作業するのは自然なことだと思いますか？

4

8 に答える 8

10

私はIceFacesで進行中の大規模なプロジェクトでSeamを使用しました。Seamは、プレーンJSFを使用するよりもはるかに優れています（上記のいくつかの回答をDamoが投稿したリンクを参照してください）。

しかし、私が覚えている問題のいくつか：

  • 単体テスト：特に継続的インテグレーションビルドでSeamT​​estを正しく機能させるのは困難でした。ウェブで、「SeamT​​estの問題」を検索してください。これも参照してください：Jboss組み込み、Seam、Mavenとの統合テストを正常に実行した人はいますか？
  • 開発者が物事を行うための複数の方法と、文書化されているベストプラクティスが多すぎないこと。したがって、時間をかけてプロジェクトチームに最適なものを見つける必要があります。たとえば、フォームを実装する場合、潜在的なタグは次のとおりです（一部が重複していることに注意してください）。

フェイスレット<ui：repeat>

JSTL <c：forEach>

JSF <h：form>

ICEFaces <ice：selectOneMenu>

JSF <f：selectitems>

縫い目<s：button>

  • 特にIceFacesの場合、パフォーマンスが疑わしいです。関連記事 もあります。また、デフォルトの方法で問題が発生する正しいことを行うには、Seamの「達人レベル」の知識が必要です。詳細については、この記事を参照してください。データ駆動型JSF/Seamアプリケーションを2桁高速化-パート1
  • Seam 3が差し迫っていて、2つの新しい仕様（JSF 2とWebBeans）を利用することになっているため、Seam 2のプロジェクトに何が起こり、安定するまでにどのくらいの時間がかかるかについて疑問が残ります。
  • 学習曲線。IMHO seamは、iText、Quartz、JExcel、jBPMなどのラッパーを提供しようとします。また、Seamとサードパーティのフレームワークとの統合は、最新バージョンよりも一歩遅れていると予想されます。たとえば、最新の機能が必要だったため、jBPMを直接統合する必要がありました。
  • JPA 1.Xに基準クエリがないためか、動的検索画面を実装する方法（ユーザーが多くのフィルターオプションを入力し、動的HQLを生成する必要がある場合）は非常にエレガントでないと感じました。これは、推奨される「SeamApplicationFramework」EntityQueryクラス。簡単な例については以下のリンクを参照してください。ただし、複雑なフィルター基準、nullの処理、順序付けなどに何が期待できるかを理解できます。EntityQueryを注文するにはどうすればよいですか。シームアプリでクエリしますか？
于 2009-08-10T06:28:06.513 に答える
6

「Seam は JSF の次のステップです」と言うのは正しくありません。Seam はビューレイヤーとして JSF を使用する必要はありません。WicketまたはGWTも使用できます。

ただし、JSF と一緒に使用すると、非常に単純化されます。標準の JSF よりも XML 構成が少なく、JSF には会話コンテキストや EL でのパラメーター化されたメソッド呼び出しなどがないことを忘れがちです。例えば：

<h:commandButton action="#{myBean.sayHello('damo')}" value="hello"/>

操作が簡単で、どこでも POJO を使用できるため、非常に解放的です。最大の欠点は、JSF に関連するものです。

  • HTTP POST への依存度が高すぎる ( s:button/link常に解決するとは限らない)
  • たくさんのジャバスクリプト
  • ゲッター/セッターへの過剰な呼び出し
  • 見栄えの悪い HTML。等

JSF の欠点を詳細に説明しているページは他にも十分すぎるほどあります(これらは Seam に対する批判ではなく、むしろ JSF1.x に対する批判であり、多くは JSF2.0 で解決されていることに注意してください)。

Seam が JSF の「次のステップ」であるとは思いませんが、JSF1.x を今すぐ使用する予定がある場合、Seam と Facelets は非常に重要です。

JSF2.0とWebBeansは次のステップだと思います。

于 2009-08-09T19:45:21.380 に答える
2

ロガーを Seam コンポーネント (例: resultList) に配置すると、Seam が同じメソッドを何度も呼び出すことがわかります。これは、Seam に関する唯一の厄介な問題です。しかし、Seam は JSF を確実に「修正」しました。JSF2 を見てみましょう。これらの問題はともかく、私は Seam を使ってとても満足しています。

于 2010-07-26T06:36:34.967 に答える
1

私はJSFが好きで、少し前にSeamを評価しました。JSFはWebUIフレームワークですが、Seamはより一般的なWebアプリケーションフレームワークであり、JSFだけでなく、会話型コンテキスト、ワークフロー（jBPM）、およびオブジェクトの永続性（EJB3が望ましい）を統合します。私は最初、宣伝されている自動生成されたスキャフォールドに魅了されましたが、エンタープライズデータモデルでそれを機能させることはできませんでした。それ以来、SpringFrameworkとSpringJSFに興味を持つようになりました。よりモジュール化されていることは私にとって魅力的であり、iBATISを使用する場合は、JBossのようなJava EEコンテナではなく、Tomcatのようなサーブレットコンテナのみが必要です。春はもう少し長くなり、マインドシェアが大きくなりました。

また、ICEfacesはJSFやファセットに最適で、SeamやSpringなどのアプリケーションフレームワークの有無にかかわらず完全に機能します。

于 2009-08-09T20:04:49.607 に答える
1

統合フレームワークとしての Seam は、使用したい他のフレームワークと組み合わせるとその有用性を発揮します。

EJB と JSF をすでに使用している場合は、SEAM が最適です。

JSF (および IceFaces や RichFaces などの関連ツール) を使用する場合、SEAM POJO はセットアップを大幅に簡素化するだけでなく、seam が提供するライフサイクル状態 (会話など) へのアクセスを提供します。 )

Wicket または GWT で EJB を使用している場合、Seam は設定を保存できる可能性もありますが、私はこの設定でそれを個人的に使用したことはありません。

すでに述べたように、Seam の欠点は抽象化フレームワークに固有のものです: 詳細が隠されています。漏れ始めたら大変です。まだ漏れたことはありませんが、それがどのように機能するかについての基本的な理解を深めるために時間を費やしました. EL が Seam アノテーションなどとどのように連携するか。

seam が役立つかどうかは、使用するフレームワークによって異なります。Seam には確かにスイート スポットがありますが、そのスポットは成長しています。Seam は決して死んだプロジェクトではありません。:)

于 2009-08-10T13:26:35.913 に答える
1

私にとっては自然なことであり、注釈を使用すると作業が楽になります。getAttribute/getParameter フレームワークで作業するなんて想像もできません。1 つの欠点は、seam-gen がまだ Maven で動作しないことです (ただし、Seam3 は Maven ベースになります)。Seam を使用すると、達成したいことに集中でき、他のフレームワークではそれを行う方法を考える必要があると思います。javascript/prototype/jquery で Ajax を実行しようとしたことがありますか? メソッド呼び出しと何をreRenderするかでAjaxボタンを縫い合わせるのと比べると本当に辛いです。Javascript は、Seam と Rich Faces ではまったく必要ありません。私にとっては、これまで使用した中で最高のフレームワークです。

于 2009-08-08T19:53:31.637 に答える
0

Factory annotationを使用して、同じメソッドを何度も呼び出すことを避けることができます。Factory を使用すると、コンポーネントを更新できます。

于 2012-06-14T16:33:37.630 に答える