我是 zope 的新手，之前在 Django 上工作了大约 2.5 年。因此，当我第一次使用 Zope(v2) 时（只是因为我的新公司已经使用它 7 年了），我面临着这些问题。请帮助我理解它们。
-
zodb 的“真正”目的是什么？我知道它的作用，但请告诉我 zodb 所做的一件伟大的事情，而像 Django（没有 zodb）这样的框架却没有做到。
更新：根据答案，Zodb 取代了对 ORM 的需求。您可以直接将对象存储在数据库中（zodb本身）。
-
据说 zope 的杀手级功能之一是 TTW（通过 Web 或使用 ZMI 开发）理念。但我（和任何开发人员）更喜欢基于文件系统的开发（使用版本控制、使用 Eclipse、使用 Zope 之外任何喜欢的工具）。那么这个TTW实际用在哪里呢？
-
这是一件大事。与 Python/Django 继承相比，Zope 的收购获得了哪些“额外的东西”。
-
从 Django 转到 Zope 真的是一个好的举措吗？
-
有类似 djangosnippets.org 的 Zope(v2) 网站吗？
I am a newbie to zope and I previously worked on Django for about 2.5 years. So when I first jumped into Zope(v2) (only because my new company is using it since 7 years), I faced these questions. Please help me in understanding them.
-
What is the "real" purpose of zodb as such? I know what it does, but tell me one great thing that zodb does and a framework like Django (which doesn't have zodb) misses.
Update: Based on the answers, Zodb replaces the need for ORM. You can directly store the object inside the db(zodb itself).
-
It is said one of the zope's killer feature is the TTW(Through the Web or Developing using ZMI) philosophy. But I(and any developer) prefers File-System based development(using Version control, using Eclipse, using any favorite tool outside Zope). Then where is this TTW actually used?
-
This is the big one. What "EXTRA Stuff" does Zope's Acquistion gain when compared to Python/Django Inheritance.
-
Is it really a good move to come to Zope, from Django ?
-
Any site like djangosnippets.org for Zope(v2)?
发布评论
评论（6）
首先，当前的 zope2 版本也包括所有 zope3。如果您查看像 Plone 这样的现代 zope2 应用程序，您会发现它在底层使用了大量“zope 3”（现在称为“zope 工具包”，ZTK）。
ZODB 的真正目的：它是为数不多的真正广泛使用的对象数据库之一（相对于关系 SQL 数据库）。您可以“仅”将所有 python 对象存储在其中，而无需使用对象关系映射器。引擎盖下没有“select * from xyz”。在 zodb 对象上添加新属性“只是”保留该更改。豪华！当您的数据无法轻松映射到严格的关系数据库时尤其方便。如果您可以轻松映射它：只需使用这样的数据库即可，我在zope项目中使用过几次sqlalchemy。
TTW：我们已经从那件事中回来了。至少，TTW的zope2方式确实有你担心的所有缺点。没有版本控制，没有外部工具等。Plone 正在尝试（谷歌搜索“灵巧性”），使用很好的明确的 zope 3 方法进行 TTW 开发，但仍然可以映射回文件系统。
TTW：zodb 可以轻松且廉价地在数据库中存储各种配置设置，因此您通常可以通过浏览器调整很多内容。不过，这并不是真正的典型 TTW 开发。
获取：方便的技巧，尽管它会导致巨大的名称空间污染。双刃剑。为了提高可调试性和可维护性，我们在大多数情况下尝试不使用。获取发生在“对象图”内部，因此请考虑“zope 站点内的文件夹结构”。如果在中间的某个位置找不到“contact_form”，则调用向下三个文件夹的“contact_form”仍然可以在网站的根目录中找到“contact_form”。双刃剑！
（当然，常规的Python面向对象继承到处都有发生）。
从 django 迁移到 zope：对于某些问题来说是一个非常好的主意，而对于其他问题来说则是无意义的:-) 很多 zope2/plone 公司实际上已经为特定项目完成了一些 django 项目，通常是那些 99% 的内容都在一个相对简单的 SQL 数据库。如果您更喜欢内容管理，zope（和 plone）可能会更好。
附加提示：不要只关注 zope2。 Zope3 的“组件架构”具有许多用于创建更大应用程序（也包括非 Web 应用程序）的功能。例如，查看 grok (http://grok.zope.org) 以获得友好的打包 zope。纯组件架构也可以在 django 项目中使用。
First things first: current zope2 versions include all of zope3, too. And if you look at modern zope2 applications like Plone, you'll see that it uses a lot of "zope 3" (now called the "zope tool kit", ZTK) under the hood.
The real purpose of the ZODB: it is one of the few object databases (as opposed to relational SQL databases) that sees real widespread use. You can "just" store all your python objects in there without needing to use an object-relational mapper. No "select * from xyz" under the hood. And adding a new attribute on a zodb object "just" persists that change. Luxurious! Especially handy when your data cannot be handily mapped to a strict relational database. If you can map it easily: just use such a database, I've used sqlalchemy a few times in zope projects.
TTW: we've come back from that. At least, the zope2 way of TTW indeed has all the drawbacks that you fear. No version control, no outside tools, etc. Plone is experimenting (google for "dexterity") with nice explicit zope 3 ways of doing TTW development that can still be mapped back to the filesystem.
TTW: the zodb makes it easy and cheap to store all sorts of config settings in the database, so you can typically adjust a lot of things through the browser. This doesn't really count as typical TTW development, though.
Acquisition: handy trick, though it leads to a huge namespace polution. Double edged sword. To improve debuggability and maintenance we try to do without in most of the cases. The acquisition happens inside the "object graph", so think "folder structure inside the zope site". A call to "contact_form" three folders down can still find the "contact_form" on the root of the site if it isn't found somewhere in between. Double edged sword!
(And regular python object oriented inheritance happens all over the place of course).
Moving from django to zope: a really good idea for certain problems and nonsensical for other problems :-) Quite a lot of zope2/plone companies have actually done some django projects for specific projects, typically those that have 99% percent of their content in a relatively straightforward SQL database. If you're more into content management, zope (and plone) is probably better.
Additional tip: don't focus only on zope2. Zope3's "component architecture" has lots of functionality for creating bigger applications (also non-web). Look at grok (http://grok.zope.org) for a friendly packaged zope, for instance. The pure component architecture is also usable inside django projects.
关于 ZODB：
另一种问“ZODB 的真正目的是什么？”的方式就是问“最初为什么创建 ZODB？”
答案是这个项目很早就开始了，大约在 1996 年。那是在 MySQL 或 PostgreSQL 出现之前，当时 miniSQL（一种免费使用但不是免费软件）数据库仍然被普遍使用，或者是大笔资金。数据库，例如 Oracle。 Python 提供了 pickle 模块来将 Python 对象序列化到磁盘 - 但序列化是较低级别的，它不允许事务、并发写入和复制等功能。这就是 ZODB 提供的功能。
它至今仍在 Zope 中使用，因为它运行良好。如果您没有关系数据库方面的现有技能，那么学习使用 ZODB 比学习使用关系数据库更容易。它还可以用于更简单的用例，例如，如果您有一个需要存储一些配置信息的命令行脚本，那么使用关系数据库意味着必须运行数据库服务器来存储一些配置信息。您可以使用配置文件，但 ZODB 也可以很好地工作，因为它是一个可嵌入的数据库。这意味着数据库与 Python 代码的其余部分在同一进程中运行。
还值得注意的是，用于在容器内存储对象的 API 在 Zope 2 和 Zope 3 之间是不同的。在 Zope 2 中，容器存储为属性：
在 Zope 3 中，它们使用与 Python 标准字典类型相同的接口：
这是另一个这就是为什么学习使用 ZODB 比学习使用 Django ORM 更容易，因为 Django 有自己的 ORM 接口，这与 Python 的现有接口不同。
通过网络 (TTW)：
同样，了解 TTW 的原因可以追溯到 Zope 开发时。虽然放弃 Subversion 或 Mercurial 等众所周知的开发工具似乎很愚蠢，但 Zope 是在 90 年代末开发的，当时唯一的免费版本控制系统是 CVS。 Zope 2 有它自己的简单版本控制功能，并且它们和 CVS 一样好（也就是说，“它们是有限的并且很糟糕。”）。当时 UNIX 工作站的成本要高得多，而且资源要少得多，因此系统管理员对服务器的管理方式更加谨慎和谨慎。 TTW 为那些通常无法通过系统管理员干预将代码上传到服务器的人提供了一种方法。
对于文本编辑器，emacs 和 vi 都有 ftp 模式，Zope 2 可以侦听 FTP 端口。这将允许您进行开发，以便将代码存储在 ZODB（可编辑 TTW）中，但通常使用 emacs 或 vi 编辑此代码。
如今，在 Zope，TTW 很少被使用或推广，因为这样做不再有意义。磁盘空间很便宜，服务器（相对）便宜，并且有很多开发人员工具希望与标准文件系统进行交互。
收购：
这是一个错误。这是一个非常令人困惑的功能，导致了许多意想不到的事情发生。从理论上讲，收购有一些有趣的想法，但在实践中，最好将其扔进垃圾箱，几乎没有实际用途。
从 Django 迁移到 Zope：
Zope 3 的工作于 2001 年开始。这解决了 Zope 2 的许多问题。这向 Zope 社区证明了 Zope 2 仍然得到积极且良好的维护，但这并不是最新状态-艺术。 Zope 2 确实只有从历史的角度来学习才有趣。
Zope 3 最终向几个不同的方向发展，因此 Zope 的现代化身最好以 Grok、BFG 或 Bobo 的形式表达。
Grok 最接近 Zope 3，因此是一个相当大的框架 - 当深入研究它的代码库时，它有时会让人不知所措。然而，就像 Django 或任何其他全栈框架一样，您不需要使用 Grok 的每个部分，学习基础知识并使用它创建 Web 应用程序可以非常容易。它的约定优于配置是首屈一指的，并且它的基于类的视图赋予它比 Django Web 应用程序更紧凑、可以说更干净的代码库。它的 URL 路由系统非常灵活，但也可以说是过度设计的。
BFG 是一个“只为你吃的东西付费”的框架，由 Zope 的长期开发者 Chris McDonough 编写。因此，它在精神上更接近 Pylons，其中只包含被认为是框架核心或必需的部分。它还与 WSGI 配合得很好。它只使用几个核心 Zope 包。
Bobo是一个“微框架”。它只是路由 URL 和提供应用程序的一种方式。它不使用任何 Zope 包，因此严格来说并不属于 Zope 系列 Web 框架。但它是由 Zope 的创建者 Jim Fulton 编写的，他最初将 Zope 的出版部分称为“Bobo”。最初的 Bobo 写于 90 年代初，将 URL 映射到包和模块，因此如果您的源代码布局为：
您可以有一个 URL，例如：
这是非常不灵活的，并在 Zope 2 中被 URL Traversel 取代，这是相当复杂的。 Bobo 使用路由，因此它是极其简单的 URL 解析和复杂 URL 解析之间的中间地带 - 复杂性与 Django 的 URL 解析机制大致相同。
On the ZODB:
Another way to ask "What is the real purpose of the ZODB?" is to ask, "Why was the ZODB originally created?"
The answer to that is the project was started very early on, around 1996. This was before the existance of MySQL or PostgreSQL, when miniSQL (a free-to-use but not free software) database was still in common use, or big money databases such as Oracle. Python provided the pickle module to serialize Python objects to disk - but serialization is lower level, it doesn't allow for features such as transactions, concurrent writes, and replication. This is what the ZODB provides.
It's still in use today in Zope because it works well. If you have no existing skillset in realational databases, it's easier to learn to use the ZODB than a relational database. It's also usable simpler use-cases, for example if you have a command-line script that needs to store some configuration information, using a relational database means having to run a database server just to store a little bit of configuraiton. You could use a config file, but the ZODB also works quite nicely because it's an embedable database. That means that the database is running in the same process as the rest of your Python code.
It's also worth noting that the API used to store objects inside containers is different between Zope 2 and Zope 3. In Zope 2, containers are stored as attributes:
In Zope 3, they use the same interface as Python standard dictionary type:
This is another reason why it can be easier to learn to use the ZODB than the Django ORM, since Django has it's own interface for it's ORM which is distinct from Python's existing interfaces.
Through-the-web (TTW):
Again, understanding the reason for TTW goes back when Zope was developed. While it seems silly to break with well known developer tools such Subversion or Mercurial, Zope was developed in the late 90s when the only free version control system was CVS. Zope 2 had it's own simple version control capabilites, and they were as good as CVS (which is to say, "they were limited and sucky."). UNIX workstations cost a lot more money back then, and had far fewer resources, so System Administrators were much more guarded and careful about how servers were managed. TTW allowed people who might not normally be able to upload code to the server with sysadmin intervation a way to do that.
With text editors, emacs and vi have had ftp-modes, and Zope 2 can listen on an FTP port. This would allow you to develop so that code was stored in the ZODB (editable TTW), but it was common to edit this code using a emacs or vi.
Today in Zope, TTW is more rarely used or promoted since it no longer makes sense to do this. Disk space is cheap, servers are (relatively) cheap, and there are lots of developer tools which expect to interact with the standard filesystem.
Acquisition:
It was a mistake. It was a very confusing feature that caused lots of unexpected things to happen. In theory there are some interesting ideas to acquisition, but in practice it's best tossed in the bin and has little practical use.
Moving from Django to Zope:
Work started on Zope 3 in 2001. This fixed a lot of the problems with Zope 2. It's a testament to the Zope community that Zope 2 is still actively and well maintained, but it's hardly state-of-the-art. Zope 2 is really only interesting to learn from a historical perspective.
Zope 3 ended up getting evolved in a few different directions, and so modern incarnations of Zope are best expressed in the form of Grok, BFG or Bobo.
Grok is closest to Zope 3, and as such is a pretty large framework - it can be rather overwhelming at times when delving through it's code base. However, just like Django, or any other full-stack framework you don't need to use every part of Grok, it can be quite easy to learn the basic and create web applications with it. It's convention-over-configuration is second to none, and it's class-based Views give it a much tighter, arguably cleaner code base than a Django web application. It's URL routing system is extremely flexible, but also arguably over-engineered.
BFG is a "pay for only what you eat" framework written by long time Zope developer Chris McDonough. As such, it's closer to Pylons in spirit, where only the parts deemed core or essential to a framework are included. It also plays very well with WSGI. It only uses a few core Zope packages.
Bobo is a "micro-framework". It's just a way to route URLs and serve up an app. It doesn't use any Zope packages, so isn't strictly in the Zope family of web frameworks. But it was written by Zope's creator, Jim Fulton, who originally called the publishing part of Zope, "Bobo". The original Bobo, written in the early 90's, mapped URLs to packages and modules, so if your source code was layed out as:
You could have a URL such as:
Which was very inflexible, and was replaced with URL Traversel in Zope 2, which is fairly complex. Bobo uses Routes, so it's a middle ground between dead-simple URL resolution and complex URL resolution - about the same in complexity as Django's URL resolution machinery.
我对这两个问题的回答都没有太多经验，但我有机会操纵这两个问题，所以我可以告诉你我对你的一些问题的看法。
通过 ZEO 的负载分配和通过 ZCatalog 的搜索。从这个角度来看，Django 的水平非常低。为了达到同样的目的，你必须重新实现很多三角形的轮子。
我很快学到的东西是：不要搞乱低级数据库问题。你会把他们搞砸的。这是一罐蠕虫，沙丘大小。
那么为什么选择 django ORM 呢？您还应该考虑是否YAGNI。 django 是简单并且自包含的，文档是优质的，当（如果）你的网站将增长这么多时，你将切换到更好的 ORM（或者在 ZODB 的情况下切换到纯 OODB） ）稍后。
我无法正确回答这个问题，但我不会说用这种方法进行开发从根本上来说是不好的。当然，这是思维方式的改变，我也倾向于更喜欢基于文件系统的开发。
Zope 3 非常模块化，因此您可以自由使用 django 中的许多组件。不过我建议不要这样做。当然可以，但我发现最大的问题是缺乏帮助。同时使用zope组件和django的人并不多。迟早，你会遇到问题，而谷歌也帮不上忙。到那时，你会意识到，如果你的生活是一场电子游戏，那么你肯定是在困难的水平上玩它（如果你必须把注意力放在 zope 代码上，也许是极端的）。
I answer without much experience on both, but I had the chance to manipulate both, so I can tell you my opinion on some of your questions.
Load distribution via ZEO and search via ZCatalog. Django is very low level on this point of view. To achieve the same, you would have to reimplement a lot of wheels, triangular.
Something I learned quite soon is: don't mess with low level database issues. You will screw them up. It's a can of worms, Dune sized.
So why choose django ORM ? You should also consider if YAGNI. django is easy and self contained, documentation is premium, and when (if) your site will grow that much, you will do the switch to a better ORM (or to a pure OODB, in case of ZODB) later on.
I cannot answer properly to this question, but I would not say that it's fundamentally bad to develop with such approach. Of course it's a change of mindset, and I tend to prefer filesystem based development as well.
Zope 3 is very modular, so you are free to use many of its components from django. I would advise against it though. You can, of course, but what I found most problematic is the lack of help. There are not many people using zope components and django at the same time. Sooner or later, you will have a problem and google won't help. At that point, you will realize that if your life was a videogame, you are definitely playing it at level difficult (maybe extreme, if you will have to put your nose into the zope code).
关于 ZODB 的一个非常好的参考是 ZODB/ZEO 程序员指南。 ZODB 不是 ORM。它是一个真正的对象数据库。 Python 对象透明地保存在数据库中，无需担心如何将它们转换为适合数据库的表示形式。任何可pickle的Python对象都可以保存在ZODB中。关系数据库适合大量平面数据（例如员工记录），而 ZODB 最适合分层数据（通常在 Web 应用程序中找到）。我个人在我的应用程序中使用 Zope 3。我从来没有做过TTW类型的工作。使用 ZODB 的最大好处是，我根本不必担心如何保存数据以及当我将软件从一个版本升级到下一版本时情况会发生怎样的变化。例如，如果我向 Python 类添加一个新属性，我所要做的就是提供一个默认值作为类属性。然后，它会自动可供使用同一类的先前版本创建的所有对象使用。删除属性是对现有对象的简单删除操作。顺便说一句，ZODB 可以在任何类型的 Python 应用程序中独立使用，并且不仅仅与 ZOPE 平台耦合。我喜欢这样一个事实：与 ZODB 相比，我在使用 Python 应用程序时不必担心 SQL 的细节。当然，如果您需要一个数据库服务器，以便可以运行由同一服务器支持的应用程序的多个副本，ZEO 可以在 ZODB 之上为您提供帮助。
Zope 最初的想法是成为一个对象发布环境。从这个角度来看，将 URL 直接映射到 ZODB 中的对象层次结构非常棒。 URL 只是反映对象的层次结构。现在就考虑确定 URL 而言，总是可以使用鹿特丹调试界面来寻求帮助。对于开发工作，我在 zope 配置中保留开发标志，并通过 Rotterdam 界面查看 ZODB 的内容。 Rotterdam 皮肤提供了一种很好的方法来检查存储在 ZODB 中的 Python 对象，并且找出更具交互性的 URL。此外，对于 ZODB 内的主要容器，我将它们注册为站点管理器（Zope 3 站点和站点管理器）内的持久实用程序。在我的代码中的任何位置，每当我需要访问此类容器时，我所做的就是 getUtility(IMyContainerType)。我什至不必记住代码库中这些容器的详细位置。它们一旦向站点管理器注册，就可以通过 getUtility() 调用在代码库内的任何地方使用。
URL 还支持命名空间。例如，使用 ++skin++ 命名空间，您可以随时更改 Web 应用程序的外观。使用++语言++命名空间，您可以随时更改用户界面的首选语言。使用 ++attributes++ 命名空间，您可以访问对象的各个属性。 URL 的功能更加强大并且更加可定制。您还可以编写遍历适配器，定义自己的命名空间，以增强 URL 的功能。举个例子，所有可以从网络界面直接访问的页面都是我的默认皮肤的一部分。虽然通过后台 AJAX 调用调用的所有页面都具有不同的外观。这样，就可以在不同的皮肤中实现不同方式的身份验证机制。在主皮肤中，如果身份验证失败，则会重定向到不同的登录页面。对于 AJAX 页面，人们可能会简单地收到 HTTP 错误。这可以集中完成。 Zope 3 对象具有接口，并且可以为多个接口定义一个视图。无论您拥有支持给定接口的对象，所有关联的视图都会自动变得可用，并且所有此类 URL 都会自动有效。如果你仔细想想，它比 URL 被硬编码的单个 python 文件或 XML 文件强大得多。我对 DJango 和 J2EE 不太了解，所以不能说它们是否具有同等的功能。
A very good reference on ZODB is ZODB/ZEO programmer's guide. ZODB is not an ORM. Its a true object database. Python objects are persisted inside the database transparently without any worries about how to transform them into a representation suitable for database. Any pickleable Python object can be saved inside the ZODB. Relational databases are suitable for large amount of flat data (like employee records) while ZODB is best for hierarchical data (typically found in web applications). I personally use Zope 3 for my applications. I never did TTW type of work. Best part of using ZODB was the fact that I never had to worry at all about how I am going to save data and how things would change when I upgrade my software from one version to next one. For example, if I add a new attribute to a Python class, all I have to do is provide a default value as a class attribute. It then becomes automatically available to all objects created with the previous version of the same class. Removing an attribute is a simple del operation on existing objects. BTW, ZODB can be used independently in any kind of Python application and isn't coupled with just ZOPE platform. I love the fact that I don't have to worry about the nitty gritties of SQL while working on Python applications thanx to ZODB. And off course if you need a database server so that you can run multiple copies of your application backed by the same server ZEO comes to your rescue on top of ZODB.
Zope started with the idea of being an Object Publishing Environment. From that perspective mapping the URL directly to the object hierarchy in ZODB was great. The URLs simply reflect the hierarchy of objects. Now so far as figuring out the URL is considered, there is always the Rotterdam debugging interface for help. For development work, I keep the development flags on in the zope configuration and look at the contents of ZODB through the Rotterdam interface. Rotterdam skin provide a great way of introspecting the Python objects stored inside the ZODB and figuring out the URLs is much more interactive. Moreover, for major containers inside my ZODB, I register them as persistent utilities inside the site manager (Zope 3 sites and site managers). Anywhere in my code, whenever I need access to such containers, all I do is getUtility(IMyContainerType). I don't even have to remember the detailed locations of those containers inside the code base. They are once registered with the site manager and going forward available anywhere inside the code base through getUtility() calls.
And the URLs also support namespaces. For example using the ++skin++ namespace, you can anytime change the skin of your web application. Using the ++language++ namespace, you can any time change the preferred language of your user interface. Using the ++attributes++ namespace you can access individual attributes of an object. URLs are simply much more powerful and much more customizable. And you can write traversal adapters, define your own namespaces, to enhance the capabilities of your URLs. To give an example, all pages which are directly accessible from the web interface, are part of my default skin. While all pages which are invoked through background AJAX calls, are under a different skin. This way, one can implement different ways of authentication mechanisms in different skins. In main skin, one is redirected to a different login page in case of authentication failure. For AJAX pages, one could simply receive an HTTP error. This could be centrally done. Zope 3 objects have interfaces and one view can be defined for multiple interfaces. Wherever you have an object which supports the given interface, all associated views become automatically available and all such URLs are automatically valid. If you think about it, its a much more powerful than a single python file or XML file where the URLs are hard-coded. I don't really know much about DJango and J2EE so cannot say if they have equivalent capability.
ZODB 是一个 OO 风格的数据库，不需要模式定义。您可以简单地创建（几乎）所有类型的对象，并将它们持久化。
TTW 有时很烦人，但您可以使用 webdav 挂载 ZOPE-object-tree。然后您可以使用您喜欢的编辑器编辑模板和脚本。
ZOPE 对于创建类似 CMS 的系统特别强大，恕我直言，它仍然是无与伦比的 - 你必须经历很多工作才能使其在 Django 中同样良好地工作。
通过 TTW，实际上像设计师这样的非开发人员有很好的机会开发模板和 CSS，而无需开发人员交互。
ZODB is a OO-style database that doesn't need a schema definition. You can simply create (nearly) all kinds of objects, and persist them.
The TTW is sometimes annoying, but you can mount the ZOPE-object-tree using webdav. Then you can edit the templates and scripts using your favorite editor.
ZOPE is especially powerful for creating CMS-like systems, IMHO there it is still unmatched - you'd have to go through a lot to make it work equally well in Django.
And through the TTW, actually non-developers like designers have a good chance of developing e.g. templates and CSS without need for developer interaction.
对上面 Wheat 的回答+1：“Zope 2 确实只有从历史角度学习才有趣”。我为一个大型网站做了几年 Zope 开发，50% 使用 zope 2，50% 使用 zope 3。即便如此（这是 2 年前），我们仍在努力将所有内容从 zope 2 迁移出来。除非你已经有很多东西了投资了现有的 Zope 2 项目，没有理由使用它；那里没有太多的未来。如果您确实有一个大型的现有 zope 2 项目，我建议您看一下名为 五（一个笑话：2 + 3 = 5）旨在
总而言之，Zope 3 是一个与 2 非常不同的框架，恕我直言，是一个更好（尽管更复杂）的框架。 TTW 是可选，在大多数情况下不推荐。隐式获取消失了。
看起来这里的人已经介绍了为什么您可能想要使用 ZODB，所以我想我应该提到关于 Zope 3（或使用 Five 的 Zope 2）的另一件事，这很好。 Zope 有一个非常强大的系统，用于将不同的应用程序组件连接在一起，称为 Zope 组件架构 (ZCA)。它允许您编写或多或少自主和可重用的组件，并且可以以标准化方式插入在一起。我现在主要做 Django 开发，有时发现自己怀念 ZCA。在 Django 中，编写可重用组件的能力是有限的并且是临时的。但是，正如 Reinout 所说，zope.component（像大多数 zope 包，包括 ZODB）在 zope 框架之外工作，可以在 Django 项目中使用。
也就是说，ZCA 有其缺点，其中之一是在 XML 文件中注册组件的过程很繁琐；我总觉得有点 Java 风格。我真正喜欢 Grok http://grok.zope.org/ 的原因之一是它位于zope.component 并为您完成许多繁重的工作。
所以底线是：Zope 2 基本上是一个死胡同。如果您的雇主愿意，请开始考虑 Zope 3，或至少是 5。我认为您会发现 Zope 3 与 Django 相比具有陡峭的学习曲线，因此通过 Grok 来学习它可能是一个好主意，它消除了 Zope 3 的许多粗糙边缘。但是，我认为对于具有大量移动部件的大型或复杂的 Web 应用程序，我会选择 Zope 而不是 Django（我是作为一个非常喜欢 Django 的人这么说的）。对于较小的项目，Django 可能会更快。不过，在这种情况下量化“大”和“小”很困难，可能还需要几千个字。如果您确实对 Zope 3 感兴趣，Philipp von Weitershausen 所著的书绝对是您的起点。
+1 on Wheat's answer, above: "Zope 2 is really only interesting to learn from a historical perspective". I did Zope dev for a large site for a couple of years, 50% zope 2, 50% zope 3. Even then (this was 2 years ago) we were working to migrate everything off of zope 2. Unless you already have a lot invested in an existing Zope 2 project, there's no reason to use it; there's just not much of future there. And if you do have a big existing zope 2 project, I'd suggest taking a look at a product caled Five (a joke: 2 + 3 = 5) that aims to
When all is said and done, Zope 3 is a very different framework from 2, and IMHO, a much better (albeit more complicated) one. TTW is optional, and not recommended for most cases. Implicit acquisition is gone.
Looks like people here have covered why you might want to use the ZODB, so I thought I'd mention one other thing about Zope 3 (or Zope 2 using Five) that's good. Zope has a very powerful system for wiring together different application components called the Zope Component Architecture (ZCA). It allows you to write components that are more or less autonomous and reusable, and which can be plugged together in a standardized way. I mostly do Django development now and I sometimes find myself missing the ZCA. In Django, the ability to write reusable components is limited and kind of ad-hoc. But, like Reinout says zope.component (like most zope packages, including the ZODB) works outside of the zope framework and could be used in a Django project.
That said, the ZCA has its drawbacks, one of which is the tedious process of registering your components in XML files; it always felt a little Java-esqe to me. One reason I really like Grok http://grok.zope.org/ is that it sits on top of zope.component and does much of that grunt work for you.
So bottom line: Zope 2 is mostly a dead end. If your employer is amenable to it, start looking at Zope 3, or at least Five. I think you'll find Zope 3 has a steep learning curve compared to Django, so it might be a good idea to come at it via Grok, which smooths out a lot of Zope 3's rougher edges. But, I think for a really large or complex web application with lots of moving parts, I'd go for Zope over Django (and I say this as someone who really likes Django a lot). For smaller projects, Django would probably be faster. Quantifying "large" and "small" in this context is hard though, and would probably require a couple of thousand more words. If you really are interested in Zope 3, the book by Philipp von Weitershausen is definitely the place to start.