一般的なWebフレームワークの主な違いは何ですか？

Question

最近では、ほとんどすべての言語で、多くのWebアプリケーションフレームワークが利用可能です。 。あなたの経験では、彼らの長所、短所、独自の特徴は何ですか？選択の余地があると仮定すると、どの要素が他のものよりも他のものを考慮するようになりますか？

私は、すべてを徹底的に比較するのではなく、1つまたは複数のフレームワークでの人々の直接的な経験に最も興味を持っています。 SOコミュニティに Rails や ASP.NET 、 Django 、 TurboGears 、または JSF 。また、誰かが Seaside や Weblocks 。

プログラミング言語は明らかな違いですが、JavaとRubyのフレーム戦争はそれほど面白くありません。これらのフレームワークのほとんどは、少なくとも選択した言語と同じくらいテクノロジー、ツール、複雑さへの投資と思われます。だから私は次のようなものにもっと興味があります：

• 開発速度と利便性
• 参入障壁-開発者トレーニングと必要なインフラストラクチャの両方の面で
• ロックイン-フレームワークを切り替える必要がある場合、どれだけのコードを保持できますか？
• 柔軟性-フレームワークはアーキテクチャまたは設計を決定しますか？ （それが良いか悪いかは、おそらく別の議論に任せるのが最善でしょう。）
• パフォーマンス、スケーラビリティ、および安定性-明らかに開発者に依存します！

Answer 1

3つの一般的なPythonフレームワークの各領域について簡単に説明します。これは私の個人的な経験と観察に基づいています。

開発速度と利便性

TurboGears 、 Pylons 、および Django の場合、開発速度はほぼ同じです。最新のフレームワークであるため、新しいサイトを簡単に開始し、ページをまとめて投げることができます。 Pythonは、開発とデバッグが非常に高速であることが有名です。Pythonフレームワークは、開発した他のどのセットアップ（PHP、Perl、Embedded Perl、C＃/ ASP.Netを含む）よりも開発時間が短いと考えています。

参入障壁-開発者トレーニングとインフラストラクチャ

Pythonを知っていて、 20分のビデオチュートリアルを視聴したい場合は、かなり完全なwikiタイプのサイトをゼロから作成できます。または、30分以内に social-bookmarkingサイトチュートリアル（インストールを含む） ）。これらはTurboGearsの例ですが、他の2つのフレームワークにもほぼ同じチュートリアルがあります。

これらのフレームワークですぐに使用できるテスト/開発インフラストラクチャは、通常、ほとんどのサイトを完了するのに十分です。いつでも、実稼働環境の要件を満たすためにコンポーネントを交換できます。たとえば、SQLiteはモデルのセットアップやテストデータの読み込みには適していますが、MySQLをインストールしてから、運用を開始するか、大量のデータを保存します。

すべての場合において、要件は非常に低く、フレームワークの特性ではなく、スケーラビリティ要件によって完全に決まります。特定のテンプレート言語またはORMに慣れている場合は、おそらくすぐにプラグインできます。

ロックイン

これは、すべてのフレームワークにわたる一般化された問題です。言語を選択すると、コードの再利用オプションが制限されます。テンプレートを選択すると、再びロックされます（ただし、一般的に他のものよりも簡単に変更できます）。 ORM、データベースなどについても同様です。これらのフレームワークがロックインを支援または妨害するような具体的なことはありません。

柔軟性

これら3つのフレームワークを使用したMVCがすべてです。あなたが言ったように、それは非常に異なる議論です！

パフォーマンス、スケーラビリティ、および安定性

まあ、良いコードを書いたら、あなたのサイトはうまくいくでしょう！繰り返しますが、これはさまざまな開発手法で対処されるすべてのフレームワークでの問題であり、おそらくこの範囲外です答えてください。

Answer 2

Django vs Struts。

開発速度と利便性。

Django-モデルの構築（Python）に必要な時間で稼働し、管理マッピング（モデルクラスごとに2〜3行のコード）を定義し、デフォルトのマスター/詳細ビューで動作するHTMLテンプレートを作成します。

Struts-SQLでデータベースを定義してから、iBatisでORMマッピングを定義する必要があります。次に、アクションクラスとJSPテンプレートページを使用して、さまざまなアプリケーションコンポーネントを定義、テスト、および構築します。ああ、アプリケーションからJSPにデータを移動するためにEJBを定義する必要があります。すべてコンパイルする必要があるので、コンパイル規則に適合するものを取得するために、多くの詳細を検討する必要があります。

参入障壁-開発者トレーニングの観点と必要なインフラストラクチャの観点の両方

すべてのフレームワークと言語で一定です。これはほとんど気にしないアイテムです。トレーニングが本質的に簡単な言語やフレームワークはありません。すべてのWebフレームワークには、同様のインフラストラクチャ要件があります。

ロックイン-フレームワークを切り替える必要がある場合、どれだけのコードを保持できますか？

これはあまり意味がありません。 TomcatからTomcat派生物に切り替えると、多くのJavaコードを保持できます。それ以外の場合、通常、フレームワークを切り替えるときに多くのコードを保持しません。

柔軟性-フレームワークはアーキテクチャまたは設計を決定しますか？ （それが良いか悪いかは、おそらく別の議論に任せるのが最善です。）

実際には、それは別の議論ではありません。それがポイントです。フレームワークがアーキテクチャを決定します-それは良いことです。実際、フレームワークは、記述、テスト、デバッグ、またはサポートする必要のないコードです。アプリケーションがフレームワークによって実証済みの実行可能な構造に限定されているのは良いことです。

パフォーマンス、スケーラビリティ、および安定性-明らかに開発者に依存します！

パフォーマンスは言語です（フレームワークではありません）。それはデザインです。ある程度、その実装構成も。

スケーラビリティはフレームワークです（言語ではありません）。設計と構成です。

OS、言語、フレームワーク、設計、プログラミング、QA、および実装構成全体の安定性。

Answer 3

これは非常に主観的な質問です。これは、質問に追加すべきタグです。いくつかのコメントがすでに示唆しているように、あなたはすでにかなり良いガイドを指定しました。あなたは実際に何を求めていますか？この種のことについては10億の意見があり、間違いなく正しい答えはありません！

個人的に、私は.htmlを使い始め、phpに移動し、rubyを試し（嫌いになった）、Python / DJangoを発見し、それ以来ずっと満足しています。これは非常にユニークな方法ですが（おそらく）走行距離が異なる場合があります：）