一般的に使用される 5 つの Python Web フレームワークの詳細な説明

Python には非常に多くのフレームワークがあり、それらを 1 つずついじることができる人は多くありません。正直に言うと、私はそのうちの 3 つしかプロジェクト開発に使用したことがなく、他のユーザーとの接触も少ししかないので、それについて話すことしかできません。知識のある友人は大歓迎です

Web フレームワークと言えば、Ruby の世界は Rails によって支配されていますが、Python は数えきれないほどのマイクロフレームワークやフレームワークが存在する百花繚乱の世界です。参照:

wiki.python.org/moin /WebFrameworks

もう 1 つの主要なスクリプト言語である PHP にも多くのフレームワークがありますが、Python Web フレームワーク (Python Web. Python コミュニティには常に多くのフレームワークが存在し、どの Python フレームワークが優れているのか、劣っているのかについての議論は 3 ～ 5 年に及ぶこともあります。

Python には非常に多くのフレームワークがあり、それらを 1 つずついじることができる人は多くありません。正直に言うと、私はそのうちの 3 つしかプロジェクト開発に使用したことがなく、他のユーザーとの接触も少ししかないので、簡単に話すことしかできません。知識のある方の追加を歓迎します。

Django

Python フレームワークは栄えていますが、依然として最大のものがあります。それが Django です。 Django が Python フレームワークの中で最高であるということについては、これに同意する人もいれば、断固として同意しない人もいます。しかし、Django が最も完全なドキュメントを持ち、最も高い市場シェアを持ち、最も多くの求人があるのであれば、誰もが異論はないと思います。 Django が賞賛されている主な点は次のとおりです:

完璧なドキュメント Django の成功の大部分は、Django のほぼ完璧な公式ドキュメント (Django 本を含む) によるものだと思います。

ソリューションの完全なセット。Rails と同様に、Django はソリューションの完全なセット (フルスタック フレームワーク + バッテリーを含む) を提供します。基本的に必要なものはすべて利用可能です (例: キャッシュ、セッション、フィード、orm、 geo、auth ) であり、Django は基本的にすべての Web サイト開発ツールを用意しているため、開発効率は言うまでもなく、問題はコード内に存在しません。 Django のソースコード内。

強力な URLルーティング構成を使用すると、Django では非常にエレガントな URL を設計でき、基本的に見苦しい GET パラメーターに別れを告げることができます。

セルフサービス管理バックエンド、管理インターフェイスは、Django で最も目を引くコントリビュートの 1 つであり、コードを 1 行も記述することなく、完全なバックエンド管理インターフェイスを実現できます。

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

テンプレート関数は比較的弱いため、Python コードに挿入することはできません。より複雑なロジックを作成するには、Python を使用してタグまたはフィルターを実装する必要があります。最近、テンプレートについて多くの議論が行われています。参考として、Python テンプレートに関する 2 つの興味深い記事があります:

1 pydanny.blogspot.com/2010/12/stupid-template-langages.html (FQ が必要です)
2 techspot .zzzeek.org/2010/12/04/in-response-to-stupid-template-langages/

URL 設定は強力ですが、すべて手作業で記述する必要があります。これは Rails の概念と完全に一致しています。設定よりも慣例 逆に、専門家と Django を初めて使用する人によって割り当てられる URL は大きく異なります。

データベース スキーマは設定されているため、問題が発生します。たとえば、多くの Web サイトでは email アドレスが一意であることが必要ですが、スキーマ内のこのフィールドの値は一意ではないため、苦労する必要があります。

一般に、Django には多くの機能があり、これを使用して Web アプリケーションを迅速に開発するのは素晴らしいことです。 Django の設計思想に従えば、Django は使いやすく、使えば使うほど使いやすくなります。逆に、Django の設計思想を受け入れられない場合、使用するのは間違いなく苦痛になります。ジャンゴ、だから早く諦めた方がいいよ。したがって、一部の人々にとってジャンゴはエリクサーと何ら変わりませんが、一部の人々にとっては毒であり、非常に有毒です。

Pylons & TurboGears & repoze.bfg

Django のほかに、もう 1 つの大きなものは Pylons です。これは、TurboGears2.x が Pylons に基づいているためです。 ze.bfg もPylons プロジェクトの大規模プロジェクトに組み込まれた 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 と repoze.bfg の統合により、Django の地位に挑戦できる次のフレームワークが誕生する可能性があります。

Tornado

& web.py

Tornado は Web サーバー (この記事では詳しく説明しません) であり、web.py のフレームワークとしての同様のマイクロフレームワークでもあります。 Tornado このアイデアは主に Web.py から来ています。Tornado のボス、Bret Taylor の次の一節も Web.py Web サイトのホームページで見ることができます (FriendFeed に関して彼がここで言及したフレームワークは、Tornado と同じものとみなすことができます)。 「[web.py は] FriendFeed で使用する Web フレームワーク [および] App Engine に同梱される Web アプリケーション フレームワークに影響を与えました…」

この関係のため、Tornado については後で個別に説明しません。

フレームワークを合理化する利点は、フレームワーク自体についてあまり心配したり、フレームワークに干渉されたりすることなく、ビジネス ロジックに集中できることです。同時に、多くのことを行わなければならないことも明らかです。自分自身のこと。

私は個人的にこの種の合理化されたフレームワークを好みます。ソースコードを読むことでフレームワーク全体の動作メカニズムを簡単に理解できるため、フレームワークのその部分があまり満足できない場合は、独自の方法で完全にモンキーパッチを適用できます。要件。

Bottle

&

Flask

Bottle と Flask は、どちらも次のような URL ルーティングを構成するためにデコレーターを使用しているのが興味深いです。 Bottle、Flask は、web.py と同様、非常に合理化されており、Bottle のすべてのコードは約 2,000 行の .py ファイル内にあります。さらに、Flask は Pylons と同様に、Jinja2、SQLAlchemy などとうまく組み合わせることができます。

しかし、Bottle または Flask のいずれかで成功した例はまだ非常に少ないです。

Quixote

なぜ私が特に Quixote について話したいのかというと、中国最大の Python で開発された Web サイトである「Douban」が Quixote を使用して開発されたからです。ソースコードをざっと調べただけで、何も調べていないので、経験があれば追加するつもりはありません。今、Doubanが開発されていれば選択肢が増えるのではないかと思っているところです。

その他(web2py, uliweb, Karrigell, Werkzeug...)

最後に、フレームワーク選択に関する誤解

フレームワークの選択に関して、多くの人が知らず知らずのうちに以下の2つの誤解に陥りがちです。 :

1. どのフレームワークが最適ですか - 世界に最適なフレームワークはありません。唯一存在するのは、あなたとあなたのチームにとって最適なフレームワークです。 プログラミング言語 選択も同様です。チームが Python に最も精通している場合は、Python を使用してください。プログラミング言語とフレームワークは単なるツールです。 、より速く、より良く、そしてより経済的です。

2. パフォーマンスに過度に注意を払う - 実際、開発する Web サイトは単に小規模な Web サイトなので、10,000 をサポートできる Web サイトは多くありません。 IP 100,000 をサポートできる Web サイトは非常に少ないです。 CPU とメモリは常にアイドル状態であるため、一定量のアクセスなしにパフォーマンスについて語るのはあまり意味がありません。さらに、言語とフレームワークは通常、パフォーマンスのボトルネックではありません。パフォーマンスの問題は、データベース アクセスとファイルの読み取りと書き込みで最もよく発生します。 PHP の Zend Framework は遅いことで有名ですが、Zend Framework には digg.com などの大きな Web サイトもあります。パフォーマンスに問題があると言われる Ruby や Rails でも twitter を開発できるのでしょうか?さらに、現在のハードウェアと帯域幅のコストは実際には非常に低く、特にクラウド コンピューティング プラットフォームの出現により、何万もの IP を持っていない場合は人件費が最も高くなります。パフォーマンスの問題については、トラフィックが増加した場合は、ある程度のお金を出してサーバーを購入してください。パフォーマンスの問題は簡単かつ迅速に解決できます。

注: 以前、一部のネチズンが「Quora は Pylons を使用して開発された」という私の発言は客観的ではないと疑問に思いましたが、ある Web サイト A が B を使用して開発された場合、それは A が主にまたは部分的に B によって開発されたことを意味するだけであることを説明してください。誰もが A を使用するか C を使用するかを心配するのをやめるべきです。

【関連おすすめ】

1. Pythonの基本入門チュートリアル

2. Python学習マニュアル

3. Pythonオブジェクト指向のビデオチュートリアル

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