故あってTurboGearsを使ってみたんだけど，うーん，これはいいや。
私のホームグラウンドであるZope/Ploneと比べて，雑感についてざっくりと書いてみます。
薄れるZODBの優位性
ZopeといえばZODB。Zopeはオブジェクトデータベース内蔵なので，別途RDBMSを立てたりする必要なく，Webアプリで利用するデータを保存できる。オブジェクトデータベース自体にはPythonのクラスインスタンスそのものが保存される。テーブルを定義する必要がない。Pythonのクラスを書けばいい。ZODBの存在が「Zopeの価値」のかなり大きな部分を占めていると言っていいと思う。
一方，ここ数年激しく進むチープ革命と，PostgreSQLやMySQLなどフリーのリレーショナルデータベースの普及によって，RDBMS運用の敷居はものすごく下がっている。その上，TurboGears搭載のSQLObjectのようなO/Rマッパーを使えば，RDBMS上のデータをPythonの文法を使ってとても手軽に扱える。てなことで，ZODBの優位性は，以前に比べてとっても薄れていると言っていいと思う。SQLObject便利すぎ。SQLObjectを使っているTurboGearsも便利すぎ。
ZODBは書き込みに弱い，という弱点を持っている。Zope(またはZODB)のスレッド数が，同時書き込み数の限界を規定する。ZopeもZODBもスレッドの粒度が高いので，スレッドを増やすために消費するコストも高い。Zopeベースで書き込みが頻発するタイプのWebアプリを運用するコストおよびリスクは，TurboGearsのようなフレームワーク+O/Rマッパー+軽いRDBMSを使った場合よりも大幅に高くなるはずだ。サービス提供を先行してユーザをあつめるような今時のサービスには，Zopeは使いづらいいんじゃないか。スケールアップするためのコストが高すぎる。ZODBがある故に，Zopeの優位性が損なわれるような状況すら考えられる。Zope3もZODBベースなので，似たような状況になると思う。
やっぱりMVC
Zope上にあるものは全部がPythonのクラスインスタンスである。Viewもデータもクラスインスタンスのアトリビュートである。開発の指針も明確なルールがないため，よくよく気をつけて開発をしないとアプリがスパゲッティな構造になって大変なことになる。その点TurboGearsは開発手法が明確でよい。モデルはここ，テンプレートはここ，みたいに置き場所が決まっていて悩むことがない。
Plone(CMF) + Archetypesとかを使うと，MVCな開発ができる。が，PloneもArchetypesも十分に複雑なフレームワークなので，別の問題がつきまとう。
学習コスト，ラーニングカーブ
ZopeもPloneも，便利な反面十分に複雑なフレームワークなので，一通り使いこなすまでに投入する「学習コスト」は大変なものになる。その点TurboGearsのような軽量のフレームワークは学習コストがかからなくて済む。ちょっとしたWebアプリを作ったことがある人なら，2,30分もうなればTurboGearsの「勘所」がつかめてくるはず。それくらいノリがいい。
テンプレート
Webアプリ構築において，テンプレートは最大の鬼門である。今時のコスメなWebアプリを開発するためには，工数のかなりの部分をテンプレート開発に費やさなければならない。テンプレートの作りはWebアプリのパフォーマンスにも影響するし，デザイナーと技術者の協調作業という頭の痛い問題もはらんでいる。でも意外と軽視されてるけどね。
Zope内蔵のZope Page Templatesというテンプレート言語もアトリビュート言語を使ってロジックを記述する。この点はとても重要である。Kidは，TurboGearsの隠れた刺客といってもいいかもしれない。
Zopeが勝っている点
Pluggableなユーザ認証
うん，ユーザ認証機能はまだまだZopeに利がある。
柔軟なセキュリティ設定
オブジェクトごとに細かい権限前提できたりとか。諸刃の剣かもしれない。
メタデータの保存とか複雑な構造を持ったオブジェクトの保存とか
メタデータとかXMLみたいに均質で複雑なデータの保存にはZODBのようなオブジェクトデータベースがやっぱり便利。医療用のアプリに使われているCache(キャシェ)なんかを見てもよくわかる。O/Rマッパー使ってもいちいちカラムとかを定義しなければならないのは辛すぎ。
あと，ファイルシステムのフォルダ構造のように，構造を持ったデータを表現するにもオブジェクトデータベースに分がある。
まとめね。
複雑な構造を持った大きめのサイトのCMSとか，複雑なWebアプリを破綻なくさっくりと実装したい場合にはZope/Ploneが向いているので使えばいいと思う。低級なフレームワークを使うより，巨大でビジネスロジック満載なZopeやPloneを使った方が，低リスク/低コストで必要なWebアプリを構築できる。
でも，今時のわりとシンプルなWebサービスを展開したい場合や，将来的に100万ユーザ規模にスケールアップしなければならない場合などは，Zopeよりも軽量言語(LL)ベースのフレームワークを使った方がいろいろと利点が多いはず。RoRとかCatalistとかDjangoとかあるわけだけど，TurboGearsのツール選択(CherryPy,SQLObject,Kid)はずば抜けて光ってる。Mochikitもハマらず使える感じでとてもいい。
ん？ JavaでDIですか。グーグー(就寝)。
追記
ZODBの特性については，石本さんが随分昔にズバリ言い当てていて，数年たった今でも状況はあまり変わっていないってことだと思います。いやはや，何年も前からPythonに目をつけていたような連中の考えることはやっぱりすごいや。やれIronPythonだ，GoogleがGvRを雇ったとかなんとか騒がれる何年も前からだもんな。
ZODBについて，最近になって変わったことと言えば，
- データベースの耐久性が上がって壊れにくくなった
- 書き込みのロックが読み込みのスレッドを妨げなくなった
- バックエンド(標準ではファイルシステム)を切り替えやすくなった
とかそんな感じかな。
負荷分散は不可能ではありません。でも，トータルコストでみるとMySQLのデータをメモリ上に置いてクラスタリングしたほうが断然安くなるはず。
フランスあたりでは，ZODBのボトルネックを改良して商売してる人たちもいるようですよ。
さらに追記
私はZopeのことをよく知っているので，なおさらTurboGearsとかDjango，Pylons，そしてRuby on Railsなどとの差が気になってしまうのかもしれない。Zopeが未だに先進的であることについては100%同意。反面，おくじさんのような優れた開発者しか，Zopeのすばらしさに気づかない，という面はあると思う。
おくじさんと一緒に働いているかずひこさんも似たようなことを言ってますね。
