一般的に使用されるいくつかの Python Web フレームワークについて深く理解する

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

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

Django

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

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

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

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

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<10;i++){

....

}

%>

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

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

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

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

Pylons & TurboGears & repoze.bfg

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

Pylons と Django の設計コンセプトは完全に異なります。Pylons 自体には約 2,000 行の Python コードしかありませんが、Pylons でほぼ使用されているいくつかのサードパーティ モジュールも付属しています。 Pylons には棚とオプションが 1 つだけ用意されており、自分の好みに応じてカスタマイズできます

テンプレート、ORM、フォーム、認証などのコンポーネントを自由に選択できるため、システムは高度にカスタマイズ可能です。 Python はグルー言語であるとよく言われますが、Pylons はグルー言語で設計されたグルー フレームワークであると間違いなく言えます。

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

· 悪夢を学習する Pylons は、Pylons が作成したものではない多くのサードパーティ ライブラリに依存しています。これらのライブラリの使用方法を学ぶために重要なのは、何を学びたいのかわからない場合があるということです。 Pylons の学習曲線は Django よりも相対的に高く、Pylons の以前の公式ドキュメントは批判の対象となっていましたが、幸いなことに、後に The Definitive Guide to Pylons という本が出版され、この状況は変わりました。このため、Pylons はかつては専門家のみに適した Python フレームワークとして知られていました。

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

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

antique バージョン 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 のような自動化されたバックエンドはおろか、セッションのサポートさえありません。

大規模な Web サイトでは、高いパフォーマンス要件の下で、フレームワークの各部分をカスタマイズする必要があることが多く、Django で開発された Web サイトの場合、各部分が継続的にカスタマイズされているとします。はい、これが最初に Tornado が提供できるものである可能性が非常に高いです。

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

HTTP サーバー

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

フロントエンドは、apache/lighttpd/nginx などを追加しなくてもブラウザからアクセスできますが、HTTP 1.1 プロトコルを完全には実装していないため、公式ドキュメントではフロントエンドで nginx を使用することをユーザーに推奨しています。運用環境、および複数の Tornado インスタンスへのバックエンド リバース プロキシ。 Tornado 自体はシングルスレッドの非同期ネットワーク プログラムであり、デフォルトで起動すると、マルチコア CPU を最大限に活用して、CPU の数に応じて複数のインスタンスを実行します。

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

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

データベース クエリは本質的にリモート ネットワーク呼び出しであり、理想的にはこれらの操作は非同期としてカプセル化されますが、Tornado はこれをサポートしていません。 システムが高トラフィックに対応するには、データベースのクエリ速度の問題を解決する必要があります。

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

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

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

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

。

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

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

以上が一般的に使用されるいくつかの Python Web フレームワークについて深く理解するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。