Java Webアプリケーション開発者として、私はこの昨年のJSF（SUN）をWebアプリケーションのフレームワークに使用しました。私はそれを使用することを非常に好きだと言わねばならず、開発が楽になります。SEAMには何らかの欠点がありますか？
最近、私はJBoss Seamについてたくさんの良いことを読んだことがありますが、まだそれを使用している人に遭遇していません。私が読んだことから、SEAMはJSFの次のステップだと思われます。
私はSEAMを使用していますので、この技術を使用しているところで何か不利な点がありましたか？あなたはそれに取り組んでいるのが自然だと感じましたか？
SEAMやGrailsのようなフレームワークの利点は、抽象度が高いことです。それはあなたのための基本的な詳細を処理し、それがうまく設計され、書かれている場合は、物事を容易にします。
SEAMやGrailsのようなフレームワークの欠点は、あなたから多くの詳細を隠すことです。下に何が起こっているのか分からない場合は、困ったときにあなたのために生成されたコードについて知りません。
もう1つの欠点は、モデルに組み込む前提が必ずしもあなたが望むものではないことです。しかし、それらを変えるということは、彼らがあなたのために定めた道を壊すことを意味します。容易ではありません。
私の助言は、フレームワークを使用し、それがもたらす利点を理解することですが、その下に起こっていることを学ぶのを止める言い訳として使用しないでください。フレームワークなしですべてを手で書くことができる人になりますが、それを提供するためにそれを使用することを選択します。
私には自然な感じがあり、アノテーションを使用すると、人生が楽になります。私はgetAttribute/getParameterフレームワークで作業することは想像もできません。 1つの欠点は、Seam-genがまだMavenで動作しないことです（Seam3はMavenベースになります）。 Seamは、達成したいことに焦点を当て、他のフレームワークではどのように行うべきか考えなければならないと考えています。あなたはjavascript/prototype/jqueryでAjaxをやろうとしたことがありますか？メソッド呼び出しと再レンダリングのためのシームAjaxボタンと比較すると、本当に面倒です。 Javascriptは本当にシームやリッチフェイスでは必要ありません。私にとってこれは私が使った最高のフレームワークです。
「SeamはJSFの次のステップです」とは言いません。 Seamはビュー層としてJSFを使用する必要はありません。また、WicketまたはGWTを使用することもできます。
しかし、JSFを使用すると、それを単純化するという素晴らしい仕事をします。標準のJSFよりもXML設定が少なく、JSFには会話コンテキストやELでパラメータ化されたメソッド呼び出しなどの機能がないことがよくあります。例：
どこでもPOJOを使用するのは簡単です。非常に自由です。これは、最大の欠点は、JSFに関連するものであります。
s:button/linkは必ずしも解決していない）HTTP POST上
Iドン - など
JSF elsewhereの欠点を詳述十分以上のページが（むしろJSF1.xのと多くはJSF2.0に解決され、これらはシームの批判ではないことに注意してください）がありますSeamはJSFの「次のステップ」だと考えていますが、今はJSF1.xを使用する予定がある場合は、Faceletが重要です。
私はJSFが好きで、ずっと前にSeamを評価しました。 JSFはWeb UIフレームワークですが、SeamはJSFだけでなく会話コンテキスト、ワークフロー（jBPM）、オブジェクト永続性（好ましくはEJB3）を統合する、より一般的なWebアプリケーションフレームワークです。私は広告された自動生成された足場によって最初にSeamに引き付けられましたが、私はそれを私のエンタープライズデータモデルで使用することはありませんでした。それ以来、私はSpring FrameworkとSpring JSFにもっと興味を持ってきました。それはもっとモジュラー的であると私に訴え、もしあなたがiBATISを使うなら、JBossのようなJava EEコンテナではなく、Tomcatのようなサーブレットコンテナだけが必要です。春は長く続いていて、心の共有が大きい。
また、ICEfacesはJSFやFaceletsにも優れています。SeamやSpringなどのアプリケーションフレームワークの有無にかかわらず、完全に機能します。
SeamはJBossを必要とせず、Tomcat/Glassfish/WebSphereでも動作しますが、Springは確かにより大きなマインドシェアを持っています。 – Damo
JEEコンテナは必須ではありませんが、SeamはEJB3でJSFを使用することを目標としています。 Springは、HibernateやiBATISなどで管理されているPOJOについて、より無関係なものとして提示されています。 –
私はIceFacesで進行中の大規模プロジェクトでSeamを使用しました。 Seamは、普通のJSFを使用するよりはるかに優れています（Damoが投稿したリンクを参照してください）。
はしかし、私が覚えている問題のいくつか：
Faceletsの< UI：フォームを実装する場合、例えば、ここで電位タグは、（それらの一部が重なることに留意されたい）であるforEachの>
JSF < H：>
JSTL < Cを繰り返します：フォーム>
ICEfacesを<氷：selectOneMenu >
JSF < F：選択項目>
シーム< S：ボタン>
Seamは、統合フレームワークとして、使用したい他のフレームワークと組み合わされたときにその有用性を実証します。
すでにEJBとJSFを使用している場合、SEAMはキラーです。
IceFacesやRichFacesなどの関連ツールを含むJSFを使用する場合は、SEAM POJOを使用すると設定が大幅に簡素化され、シームが提供するライフサイクルの状態にアクセスできます（会話など）
WicketまたはGWTでEJBを使用している場合、Seamは設定を保存することができますが、この設定では個人的に使用していません。
前述のように、Seamの欠点は、抽象化フレームワークに固有のものです。それは、あなたの詳細を隠しているからです。それが漏れ始めるなら、あなたは困っている。私はまだそれが私の上に漏れていたわけではありませんが、私はまた、それがどのように動作するのか良い、基本的な理解を与えるために時間を費やした。 ELがどのようにSeam Annotationsなどで動作するか。
有用な継ぎ目を見つけるかどうかは、それを使用するフレームワークによって異なります。 Seamは間違いなくスイートスポットを持っていますが、そのスポットは成長しています。 Seamは間違いなく死んだプロジェクトではありません。:)
Seamコンポーネント（たとえばresultList）にloggerを置くと、Seamが同じメソッドを何度も呼び出すことがわかります。 これはSeamに関する唯一の厄介な痛みです。しかし、SeamはJSFを「固定」していますが、これはかなり混乱しています。 JSF2を見てみましょう。 これらの問題にかかわらず、私はSeamを使用して非常にうれしく思います。
Factory annotationを使用して、同じメソッドへの呼び出しを何度も繰り返さないようにすることができます。 Factoryでは、コンポーネントを更新できます。
+1「フレームワークなしで手全体を書くことができるが、それを提供するために使用することを選択してください。 – firstthumb
これは、技術的な説明よりも哲学と原則です。私はそれが好きです:) –