一般的に使用されるいくつかの Python Web フレームワークの簡単な分析

さまざまな言語プラットフォームの中で、Python はおそらく最も多くの Web フレームワークが登場しており、無数のマイクロフレームワークやフレームワークが存在し、百花繚乱の世界です。その理由は、Python でフレームワークを構築するのが非常に簡単だからだと思います。ホイールを回転し続けることが発明されました。したがって、

Python コミュニティでは、Python フレームワークの長所と短所についてのトピックが常に存在します。いくつかの主要な Python フレームワークを紹介します。

Django

Django は最も有名な py フレームワークです。Google App Engine や Erlang にも影響を受けるフレームワークがあります。

Django は、完全に自動化された管理バックエンドで最も有名です。ORM を使用して簡単なオブジェクト定義を行うだけで、データベース構造とフル機能の管理を自動的に生成できます。 。

Django によって提供される利便性は、Django の組み込み ORM がフレームワーク内の他のモジュールと高度に結合されていることも意味します。

アプリケーションは Django の組み込み ORM を使用する必要があります。そうしないと、フレームワークで提供されるさまざまな ORM ベースの利便性を享受できなくなります。理論的には、その ORM モジュールを切り替えることができますが、これは解体に相当します。飾り付けられた家 模様替えするなら、最初からラフな部屋に行って真新しい飾り付けをした方が良いです。

Django のセールスポイントはその超高い開発効率ですが、そのパフォーマンスの拡張には限界があり、トラフィックが一定の規模に達した後、パフォーマンス要件を満たすために Django を使用するプロジェクトを再構築する必要があります。

Django の欠点は主に、Django がすべてのホイールを独自に作成することにこだわっているためです。 Django の最も批判されている側面は次のとおりです。

· システムが密結合していると感じた場合。 Django に組み込まれている特定の機能があまり良くありません。まあ、後述する ORM や Template など、好みのサードパーティ ライブラリに置き換えるのは困難です。 Django で SQLAlchemy や Mako を使用することはほぼ不可能であり、いくつかのパッチがあっても、非常に非常にぎこちなく感じるでしょう。

· Django に付属する ORM は SQLAlchemy よりもはるかに強力ではありません。Django を除いて、SQLAlchemy は Python の世界における事実上の ORM 標準です。しかし、Django は依然として独自のセットを主張しています。 Django の

開発者も SQLAlchemy をサポートするために議論し試みましたが、コストが高すぎるため、他の Django モジュールと統合するのは難しいと推定されています。

· Template 関数は比較的弱いため、Python コードに挿入することはできません。より複雑なロジックを作成するには、Python を使用してタグまたはフィルターを実装する必要があります。 Django のテンプレート システムの設計は非常に興味深いものであり、そのフレームワークの中で最も影響力があり、物議を醸す部分となるはずです。

Django テンプレートの設計理念は、コードとスタイルを完全に分離することです。asp.net はコードとテンプレートを分離することを推奨していますが、技術的には依然として混合することができますが、Django ではテンプレート データのコーディングと処理が基本的に排除されています。

たとえば、asp.net テンプレートでは次のように記述できます:

int i;

for(i==0;i

....

}

%>

Django は上記のような埋め込みコードをまったくサポートしておらず、テンプレートの組み込み関数のみを使用できます。これにより、実際にはテンプレートの「新しい言語」が構築されます。新しい言語」 非常にシンプルなので、そのテンプレートはさまざまなプラットフォームに移植することもできます。

ほとんどの場合、Django のテンプレート機能で十分ですが、特別な状況 (「特別」がそれほど特別ではない場合もあります) では、テンプレートにコードを埋め込む必要があり、その場合はそのテンプレート システムのルールに従う必要があります。テンプレート拡張機能を作成します。場合によっては、テンプレートに 1 行のコードで

を直接記述することで解決できる問題が、テンプレート拡張機能を使用して実装すると、数十行以上のコードになる場合があります。

テンプレートでのプログラミングが許容されるかどうかは、Django テンプレートの最も物議を醸す側面です。

Pylons & TurboGears & repoze.bfg

Django のほかに、もう 1 つの大きなものは Pylons です。TurboGears2.x は Pylons に基づいており、repoze.bfg も Pylons プロジェクトのこの大規模プロジェクトに組み込まれているためです。ここでは、TurboGears と repoze.bfg については後で個別に説明しません。

Pylons と Django の設計コンセプトは完全に異なります。Pylons 自体には Python コードが約 2,000 行しかありませんが、Pylons でほぼ使用されているいくつかのサードパーティ モジュールも付属しています。 Pylons は 1 つのシェルフとオプションのソリューションのみを提供し、独自の好みに応じて、テンプレート、ORM、フォーム、認証などのコンポーネントを自由に選択できます。 Python はグルー言語であるとよく言われますが、Pylons はグルー言語で設計されたグルー フレームワークであると間違いなく言えます。

Pylons を選択することは、おそらくその自由を選択していることを意味します:

· 悪夢を学習する Pylons は、Pylons が作成したものではない多くのサードパーティ ライブラリに依存しています。これらのライブラリの使用方法を学ぶには、何を学びたいのかが分からないことが重要です。 Pylons の学習曲線は Django の学習曲線よりも比較的高く、

パイロンに関する以前の公式文書は常に批判の対象でした。幸いなことに、後に『The Definitive Guide to Pylons』という本が出版され、この状況は変わりました。このため、Pylons はかつては専門家のみに適した Python フレームワークとして知られていました。

· デバッグは悪夢です。多くのモジュールが関係しており、一度エラーが発生すると、問題を特定するのが困難です。あなたが書いたプログラムのせいかもしれないし、Pylons が間違っているかもしれないし、SQLAlchemy が間違っているかもしれないし、あるいは formencode にバグがあるかもしれません。とにかく、非常に厄介です。この問題は、それに精通している場合にのみ解決できます。

· Pylons をインストールするには、それぞれ独自のバージョン番号を持つ 20 個近くの Python モジュールをインストールする必要があり、どのモジュールでも互換性の問題が発生する可能性があります。難しい。これまでのところ、reddit の Pylons はまだ

アンティーク バージョン 0.9.6 のままで、SQLAlchemy はまだバージョン 0.5.3 のままですが、これはこれに関連しているはずです。

Pylons と repoze.bfg の統合により、Django の地位に挑戦できる次のフレームワークが誕生する可能性があります。

Tornado & web.py

Tornado ( http://www.tornadoweb.org ) は、Facebook のオープンソース フレームワークであり、その哲学は Django とはほぼ逆です。 Tornado は Web サーバー (この記事では詳しく説明しません) であり、web.py に似たマイクロ フレームワークでもあります。

Tornado は、より正確ではありますが、テンプレート機能も提供します。推奨されていませんが、作成者はテンプレートに少量のコーディングを許可できます (py コードを 1 行直接埋め込みます)。

asp.net と比較すると、Tornado は少し似ており、AsyncHttpHandler のみを実装します。それ以外はすべて自分で実装する必要があります。

実際、テンプレート、国際サポート、さらにはサードパーティのログインを容易にする組み込みの OAuth/OpenID モジュールがあり、実際には HTTP サーバーを直接実装しています。

しかし、ORM はなく (mysql の非常に単純なカプセル化だけ)、Django のような自動化されたバックエンドはおろか、セッション サポートさえもありません。

高パフォーマンスの要件の下で、フレームワークの各部分をカスタマイズする必要があることが多く、Django で開発された Web サイトでは再利用できるモジュールがほとんどないとします。継続的にカスタマイズされており、Django フレームワーク 残りはおそらく、tornado が最初から提供できるものです。

異なる道は同じ目的地につながります。

HTTP サーバー

Comet/バックエンドの非同期呼び出しを HTTP インターフェースに効率的に実装するために、Tornado は HTTP サーバーを直接埋め込みます。

フロントエンドは、apache/lighttpd/nginx などを追加しなくてもブラウザからアクセスできますが、HTTP 1.1 プロトコルを完全には実装していないため、公式ドキュメントではフロントエンドで nginx を使用することが推奨されています。運用環境では、バックエンド プロキシを複数の Tornado インスタンスに反転します。

Tornado 自体は、デフォルトで起動されると、マルチコア CPU を最大限に活用して、複数のインスタンスを実行します。

シングルスレッドの非同期

Web サイトは基本的にデータベース操作を行いますが、Tornado はシングルスレッドです。つまり、データベース クエリの戻りが遅すぎると、サーバーの応答全体がブロックされます。

データベース クエリは本質的にリモート ネットワーク呼び出しであり、理想的にはこれらの操作は非同期としてカプセル化されますが、Tornado はこれをサポートしていません。

システムが高トラフィックに対応するには、データベースのクエリ速度の問題を解決する必要があります。

データベースにクエリのパフォーマンスの問題がある場合、システム全体がどのように最適化されていても、データベースがボトルネックとなり、システム全体の速度が低下します。

非同期は**本質的に** システムのパフォーマンスを向上させません。ネットワーク応答の不要な待機とスイッチング スレッドの CPU 消費を回避するだけです。

データベース クエリの応答が遅すぎる場合、解決する必要があるのは、データベースを呼び出すフロントエンド Web アプリケーションではなく、データベースのパフォーマンスの問題です。

リアルタイムで返されるデータ クエリの場合、理想的には、すべてのデータがメモリ内にあることを確認する必要があり、データベース ハード ディスク IO が 0 である必要があり、データベース クエリが高速であれば、そのようなクエリは十分に高速である必要があります。十分であれば、フロントエンド Web アプリケーションもデータ クエリを非同期としてカプセル化する必要はありません

。

コルーチンを使用する場合でも、非同期プログラムは常に同期プログラムの複雑さを増大させます。測定する必要があるのは、これらの追加の複雑さに対処する価値があるかどうかです。

バックエンドに遅すぎてバイパスできないクエリがある場合、Tornado の提案は、これらのクエリをバックエンドで独立して HTTP インターフェイスにカプセル化し、Tornado の組み込み非同期 HTTP クライアントを使用して呼び出しを行うことです。