私はここ数年、小さなサイトのプロトタイピングにTurbogears 1を使用してきましたが、少し長くなっています。Turbogears 2にアップグレードするか、Djangoのようなものに切り替えるかの間で電話をかけることについて何か提案はありますか？私は、非常に応答性が高く、非常に優れたドキュメントを作成するTGコミュニティと、Djangoを使用するはるかに大規模なコミュニティに精通していることに悩まされています。組み込みのCMS機能とGoogleAppEngineのサポートに非常に興味があります。
何かアドバイス？
TG2は、かなり大きなコミュニティを持つPylonsの上に構築されています。TGはTG1と比較して高速になり、メソッドごと（Webページだけでなく）のキャッシングエンジンが含まれています。ページをHTMLまたはJSONで簡単に公開できるという点で、DjangoよりもAJAXに適していると思います。
2011年の更新：3年間の肥大化したフレームワークの後、私はhttp://bottlepy.org/の幸せなユーザーです。
私はDjangoとTG1.1の両方の経験があります。
IMO、TurboGearsの長所は、ORM：SQLAlchemyです。データベース側が重要な場合、私はTurboGearsを好みます。
DjangoのORMは、それほど柔軟で強力ではありません。
そうは言っても、私はDjangoが好きです。データベーススキーマがDjangoのORMに適している場合は、Djangoを使用します。
私の経験では、TurboGearsと比較してDjangoを使用する方が簡単です。
私はDjangoを1年間使用していますが、始めたときはPythonやDjangoの経験がなく、非常に直感的に使用できることがわかりました。
私はDjangoを使用して多くの趣味のGoogleAppEngineアプリを作成しましたが、最新のアプリは私のサイトのCMSです。Djangoを使用することで、コーディングが大幅に高速化され、バグが大幅に減少しました。
TurboGearsとDJangoのWeb上の比較をたくさん読んだことでしょう。
しかし、CMSとGAEに対するあなたの誘惑については、DJangoの道を歩む必要があると本当に思います。これらをチェックして、自分で決めてください。
質問は1つだけです...開発しているアプリは、ソーシャルネットワーキングまたはカスタマイズされたビジネスロジックを対象としていますか？
個人的には、柔軟性があり、境界がないことが本当に必要な場合は、Djangoがソーシャルネットワーキングやパイロン/ターボギアに適していると思います...
ちょうど私の2c
TG2は、複数のエラーメッセージが表示されるログインページのように、いくらか単純なものであっても、非常に複雑で混乱しているように見えます 。Turbogears2.1のログイン機能 を拡張する方法
Django ORMはアクティブレコードの実装を使用します–この実装はほとんどのORMで見られます。基本的には、データベースの各行がコード内のオブジェクトに直接マップされ、その逆も同様です。DjangoなどのORMフレームワークでは、コード内のプロパティを使用するためにスキーマを事前に定義する必要はありません。フレームワークはデータベーススキーマを調べることで構造を「理解」できるため、これらを使用するだけです。また、レコードはテーブルの特定の行にマップされているため、データベースに保存することもできます。
SQLAlchemyはデータマッパー実装を使用します–この種の実装を使用する場合、データベース構造とオブジェクト構造が分離されます（Active Record実装のように1：1ではありません）。ほとんどの場合、データベースとの対話を維持するために（たとえば、オブジェクトを保存するために）、別の永続層を使用する必要があります。したがって、Active Record実装（これは短所です）を使用するときにできるようにsave（）メソッドを呼び出すことはできませんが、一方で、コードが機能するためにデータベース内のリレーショナル構造全体を知る必要はありません。 、コードとデータベースの間に直接の関係がないため。
では、どちらがこの戦いに勝ちますか？なし。それはあなたが達成しようとしていることに依存します。アプリケーションのほとんどがCRUD（作成、読み取り、更新、削除）アプリケーションであり、さまざまなデータエンティティ間の関係に適用するハードで複雑なルールがない場合は、Active Record実装（Django）を使用する必要があると思います。これにより、面倒なことなく、製品のMVPを簡単かつ迅速に設定できます。アプリケーションに多くの「ビジネスルール」と制限がある場合は、データマッパーモデルを使用した方がよい場合があります。これは、Active Recordのように拘束されたり、厳密に考えたりする必要がないためです。