2

ERP システムの開発に使用できるフレームワークを研究しています。

私はSpringを使ったことがなく、それについてまったく知りません。しかし、私は長い間Tapestry IoCを使用していますが、すべての機能を使用していません.

ここに私がこれまでに到達したものがあります：

Tapestry IoC アプリケーションは、モジュール (JAR ファイル) 間で簡単に配布できます。各モジュールは、次のものに貢献できます。

  • サービス定義
  • サービス構成: コレクションを使用してサービスを構築できます。これらのコレクションは、さまざまなモジュールから提供できます。ただし、そのコレクション内の要素の条件付きオーバーライド、オーバーライドするかどうかを決定する前に提供された構成要素をチェックするなど、いくつかの制限があります。

(私が間違っている場合は、私を修正することを歓迎します)

Tapestry IoC には他にもたくさんあります。それについては確かです。まだ調べていません。

私の主な関心事は、異なる JAR ファイルのようにモジュール間でアプリケーションを配布することです。これにより、新しい機能を簡単かつ安全にプラグインできます。

Tapestry IoC と Spring IoCの最新バージョンを使用した人はいますか?

  • Spring は Tapestry のような分散構成の概念を提供しますか?
  • これらのフレームワークのどの側面で他のフレームワークよりも優れていますか?
  • 春は短期間で簡単に習得できますか？
  • GWT や SmartGWT などの ajax ベースのフロントエンドと統合するのに、どちらがより簡単で効率的でしょうか?
  • セキュリティ、パイプライン、スケジューリング、トランザクション (および提案するその他のサービス) などのエンタープライズ サービスを提供する上で、より簡単で効率的なのはどれですか?
  • 他に質問すべきことはありますか???
4

3 に答える 3

1

私は 2008 年に GWT と Tapestry を使用しました。うまく機能し、セットアップも非常に簡単でした。私は今、タペストリーのプロジェクトを自分でやっているので、とてもはまっています。

Spring IOC は非常に理解しやすく、習得しやすいことがわかりました。週末かそこらで基本を学ぶことができるはずです。

反対側のタペストリーはマスターするのが少し難しいですが、はるかにやりがいがあります. タペストリー IOC は他の多くの環境でも再利用可能であり、単純な非 Web 関連プロジェクトにも使用しています。Tapestry Documentationは、最近の方がはるかに優れています。また、Tapestry のJumpstart Demo Applicationは、基本的なトピックとより高度なトピックの説明とテストに非常に適しています。

タペストリーの利点は、一度理解すれば使いやすいことです。ソースコードに飛び込むのは簡単で、理解するのにそれほど問題はありません。そもそもプロキシであるサービスが嫌いです。しかし、それはもっと味です。

また、タペストリーはそれに値する勢いを得ていないことにも注意してください. そして当然のことながら、Tapestry の @CommitAfter メカニズムは 2008 年当時と同じように壊れており、担当者に修正してもらうことができませんでした。（私は最近試しましたが、また失敗しました）。

タペストリーの残りの部分は、使用する喜びです。

一方、春には多くのビジネス サポートと大量の情報があります。また、Java の世界でも広く使用されています。ですから、それに取り掛かると、プロの履歴書の強力な資産になります。

ですから、最終的には自由に選択できます。私の心はタペストリーに行くと言っていますが、私の脳は春が勝つと言っています。心に従うと幸せになりますが、頭脳に従うとよりうまくいくので、答えは明らかです。春が圧倒的に勝ちます。しかし、数日を空けて、Tapestry も試してみてください。特に、Tapestry IOC は非常に再利用可能なツールであり、プログラマーの日常生活のあらゆる場面で役立つ可能性があります。

于 2013-09-29T17:51:34.127 に答える
1

安全な答えは常にSpringです（ストラットと同じ;））。

春の利点は、それに関するより多くのソース (本、記事、ブログ投稿) を見つけることができることです。したがって、大量の例が必要な場合、Spring は非常に簡単です。特に、誰かがすでに Spring と GWT を一緒に使用しようとしている可能性があります。また、Spring の最新バージョンは、構成に関してはそれほど悪くありません ;)

一方、タペストリーは非常に強力です。すぐに使用できる多くのもの (例: モジュール化について言及) を入手できますが、Spring では可能ですが、それらがそのまま使用できるかどうかはわかりません (おそらく、2.0 以降、Spring をそのように使用したことはありません)。 ）。言及する価値があるのは、Tapestry では Spring を完全にサポートしているため、T5 で何かが機能しない場合でも、Spring Bean を作成して T5 で使用できるということです ^^

于 2013-09-19T05:55:10.150 に答える
0

tapestryIoc と別の IoC フレームワークの比較を見つけることができます。

から: http://tapestry.apache.org/ioc.html

Spring は、最も成功した IoC コンテナー プロジェクトです。Spring プロジェクトは、非常に優れた IoC コンテナ、統合された AspectJ サポート、およびコンテナ上に構築された多数のライブラリを組み合わせています。Spring は優れたアプリケーション コンテナーですが、フレームワーク コンテナーに必要な多くの機能が欠けています。

Spring Bean は名前 (または ID) で結び付けることができますが、追加の命名抽象化を導入することはできません。Tapestry 4 の "infrastructure:" 抽象化は、相互に関連するサービスの大規模な Web (Tapestry 4.0 では約 200) を複製することなく、内部の Tapestry サービスを簡単に上書きできるようにするための鍵でした。

Spring では Bean をインターセプトできますが、これは新しい Bean の形で行われ、インターセプトされていない Bean が表示されたままになります (悪用される可能性があります)。Tapestry IoC は、サービスをインターセプター内に「ラップ」し、コア サービス実装への傍受されないアクセスを防ぎます。

Spring の XML 構成ファイルは非常に冗長です。これは Spring 2.0 で改善されましたが、T5 IoC モジュール クラスよりもはるかに冗長です。

Spring には単純なマップ/リスト/値構成スキームがありますが、分散されていません。これは単一の Bean 定義の一部です。Tapestry 5 IoC では、サービス構成を複数のモジュールから組み立てることができます。これは、フレームワークのシームレスな拡張性にとって非常に重要です。構成は不要です (モジュールをクラスパスにドロップするだけで、すべてが接続されます)。

于 2013-09-26T06:53:07.810 に答える