我是 zope 的新手，我之前在 Django 上工作了大约 2.5 年。所以当我第一次进入 Zope(v2) 时（只是因为我的新公司已经使用了 7 年），我遇到了这些问题。请帮助我理解它们。
zodb 的“真正”目的是什么？我知道它的作用，但请告诉我 zodb 所做的一件很棒的事情，而像 Django（没有 zodb）这样的框架却错过了。
更新：根据答案，Zodb 取代了对 ORM 的需求。您可以直接将对象存储在 db（zodb 本身）中。
据说 zope 的杀手级功能之一是 TTW（通过 Web 或使用 ZMI 开发）理念。但是我（和任何开发人员）更喜欢基于文件系统的开发（使用版本控制，使用 Eclipse，使用 Zope 之外的任何喜欢的工具）。那么这个TTW实际用在哪里呢？
这是最大的。与 Python/Django 继承相比，Zope 的收购获得了什么“额外的东西”。
从 Django 来到 Zope 真的是个好举动吗？
任何像 djangosnippets.org 这样的 Zope(v2) 网站？
首先要做的事情是：当前的 zope2 版本也包括所有的 zope3。如果你看看现代的 zope2 应用程序，比如 Plone，你会发现它在底层使用了很多“zope 3”（现在称为“zope 工具包”，ZTK）。
ZODB 的真正目的是：它是少数真正被广泛使用的对象数据库（与关系 SQL 数据库相反）之一。您可以在其中“仅”存储所有 python 对象，而无需使用对象关系映射器。引擎盖下没有“从 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 项目中使用。
在 ZODB 上：
另一种问“ZODB 的真正目的是什么？”的方式。就是要问，“ZODB 最初为什么要创建？”
答案是这个项目很早就开始了，大约在 1996 年左右。那是在 MySQL 或 PostgreSQL 出现之前，当时 miniSQL（一种免费但不是免费的软件）数据库仍然普遍使用，或者说是大笔资金Oracle 等数据库。Python 提供了 pickle 模块来将 Python 对象序列化到磁盘 - 但序列化级别较低，它不允许事务、并发写入和复制等功能。这就是 ZODB 提供的。
它今天仍在 Zope 中使用，因为它运行良好。如果您没有关系数据库方面的现有技能，学习使用 ZODB 比使用关系数据库更容易。它也适用于更简单的用例，例如，如果您有一个需要存储一些配置信息的命令行脚本，则使用关系数据库意味着必须运行数据库服务器来存储一些配置信息。您可以使用配置文件，但 ZODB 也可以很好地工作，因为它是一个可嵌入的数据库。这意味着数据库与其他 Python 代码在同一进程中运行。
还值得注意的是，Zope 2 和 Zope 3 用于在容器中存储对象的 API 是不同的。在 Zope 2 中，容器作为属性存储：
root.mycontainer.myattr
在 Zope 3 中，它们使用与 Python 标准字典类型相同的接口：
root['mycontainer']myattr
这是学习使用 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 映射到包和模块，所以如果您的源代码布局为：
mypackage.mymodule.MyClass
您可以有一个 URL，例如：
/mypackage/mymodule/MyClass
这非常不灵活，在 Zope 2 中被相当复杂的 URL Traversel 取代。Bobo 使用路由，因此它是非常简单的 URL 解析和复杂的 URL 解析之间的中间地带 - 与 Django 的 URL 解析机制的复杂性大致相同。
我在这两个方面都没有太多经验，但我有机会操纵两者，所以我可以告诉你我对你的一些问题的看法。
1）zodb的“真正”目的是什么？意思是我知道它的作用，但请告诉我 zodb 所做的一件很棒的事情，以及像 django（没有 zodb）这样的框架错过了
通过 ZEO 进行负载分配并通过 ZCatalog 进行搜索。从这个角度来看，Django 的水平非常低。为了达到同样的效果，你必须重新实现很多轮子，三角形的。我很快学到的是：不要搞低级别的数据库问题。你会把他们搞砸的。这是一罐蠕虫，沙丘大小。
那么为什么选择 django ORM 呢？您还应该考虑是否YAGNI。django简单且自包含，文档是优质的，当（如果）您的网站增长如此之多时，您将在稍后切换到更好的 ORM（或纯 OODB，如果是 ZODB）。
2）据说zope的杀手锏之一就是TTW（Through the Web or Developing using ZMI）哲学。但是我（和任何开发人员）更喜欢基于文件系统的开发（使用版本控制，使用 Eclipse，使用 Zope 之外的任何喜欢的工具）。那么这个TTW实际用在哪里呢？
我无法正确回答这个问题，但我不会说用这种方法开发从根本上是不好的。当然，这是思维方式的改变，我也更喜欢基于文件系统的开发。
4）从 Django 开始在 Zope 上工作真的是一个很好的举措吗？
Zope 3 是非常模块化的，因此您可以自由地使用来自 django 的许多组件。我建议不要这样做。你当然可以，但我发现最大的问题是缺乏帮助。同时使用zope组件和django的人并不多。迟早，您会遇到问题，而谷歌将无济于事。到那时，您会意识到，如果您的生活是一个电子游戏，那么您肯定会在难度级别上玩它（如果您不得不将自己的鼻子放在 zope 代码中，可能会非常困难）。
ZODB 的一个很好的参考是ZODB/ZEO 程序员指南. ZODB 不是 ORM。它是一个真正的对象数据库。Python 对象透明地保存在数据库中，无需担心如何将它们转换为适合数据库的表示。任何可腌制的 Python 对象都可以保存在 ZODB 中。关系数据库适用于大量平面数据（如员工记录），而 ZODB 最适合分层数据（通常在 Web 应用程序中找到）。我个人将 Zope 3 用于我的应用程序。我从来没有做过TTW类型的工作。使用 ZODB 最棒的一点是，当我将软件从一个版本升级到下一个版本时，我完全不必担心如何保存数据以及事情会如何变化。例如，如果我向 Python 类添加一个新属性，我所要做的就是提供一个默认值作为类属性。然后，它自动可用于使用同一类的先前版本创建的所有对象。删除属性是对现有对象的简单 del 操作。顺便说一句，ZODB 可以在任何类型的 Python 应用程序中独立使用，并且不仅仅与 ZOPE 平台耦合。我喜欢这样一个事实，即在使用 Python 应用程序时，我不必担心 SQL 的细节，而不是 ZODB。当然，如果您需要一个数据库服务器，以便您可以运行由同一服务器支持的应用程序的多个副本，ZEO 会在 ZODB 之上为您提供救援。我喜欢这样一个事实，即在使用 Python 应用程序时，我不必担心 SQL 的细节，而不是 ZODB。当然，如果您需要一个数据库服务器，以便您可以运行由同一服务器支持的应用程序的多个副本，ZEO 会在 ZODB 之上为您提供救援。我喜欢这样一个事实，即在使用 Python 应用程序时，我不必担心 SQL 的细节，而不是 ZODB。当然，如果您需要一个数据库服务器，以便您可以运行由同一服务器支持的应用程序的多个副本，ZEO 会在 ZODB 之上为您提供救援。
Zope 最初的想法是成为一个对象发布环境。从这个角度来看，将 URL 直接映射到 ZODB 中的对象层次结构非常棒。URL 只是反映对象的层次结构。现在只要考虑弄清楚 URL，总是有鹿特丹调试界面寻求帮助。对于开发工作，我在 zope 配置中保持开发标志打开，并通过 Rotterdam 界面查看 ZODB 的内容。鹿特丹皮肤提供了一种很好的方式来内省存储在 ZODB 中的 Python 对象，并且找出 URL 更具交互性。此外，对于我的 ZODB 中的主要容器，我将它们注册为站点管理器（Zope 3 站点和站点管理器）中的持久实用程序。在我的代码中的任何地方，每当我需要访问这些容器时，我所做的就是getUtility(IMyContainerType)。我什至不必记住这些容器在代码库中的详细位置。它们一旦在站点管理器中注册，就可以通过 getUtility() 调用在代码库内的任何地方使用。并且 URL 还支持命名空间。例如，使用 ++skin++ 命名空间，您可以随时更改 Web 应用程序的外观。使用 ++language++ 命名空间，您可以随时更改用户界面的首选语言。使用 ++attributes++ 命名空间，您可以访问对象的各个属性。URL 更强大，更可定制。您可以编写遍历适配器，定义自己的命名空间，以增强 URL 的功能。举个例子，可以从 Web 界面直接访问的所有页面，是我默认皮肤的一部分。虽然通过后台 AJAX 调用调用的所有页面都在不同的皮肤下。这样，可以在不同的皮肤中实现不同的身份验证机制。在主皮肤中，如果身份验证失败，将重定向到不同的登录页面。对于 AJAX 页面，人们可以简单地收到一个 HTTP 错误。这可以集中完成。Zope 3 对象具有接口，并且可以为多个接口定义一个视图。无论您有一个支持给定接口的对象，所有关联的视图都将自动可用，并且所有此类 URL 都自动有效。如果您考虑一下，它比 URL 是硬编码的单个 python 文件或 XML 文件强大得多。我对 DJango 和 J2EE 了解不多，所以不能说它们是否具有同等的能力。虽然通过后台 AJAX 调用调用的所有页面都在不同的皮肤下。这样，可以在不同的皮肤中实现不同的身份验证机制。在主皮肤中，如果身份验证失败，将重定向到不同的登录页面。对于 AJAX 页面，人们可以简单地收到一个 HTTP 错误。这可以集中完成。Zope 3 对象具有接口，并且可以为多个接口定义一个视图。无论您有一个支持给定接口的对象，所有关联的视图都将自动可用，并且所有此类 URL 都将自动有效。如果您考虑一下，它比 URL 是硬编码的单个 python 文件或 XML 文件强大得多。我对 DJango 和 J2EE 了解不多，所以不能说它们是否具有同等的能力。虽然通过后台 AJAX 调用调用的所有页面都在不同的皮肤下。这样，可以在不同的皮肤中实现不同的身份验证机制。在主皮肤中，如果身份验证失败，将重定向到不同的登录页面。对于 AJAX 页面，人们可以简单地收到一个 HTTP 错误。这可以集中完成。Zope 3 对象具有接口，并且可以为多个接口定义一个视图。无论您有一个支持给定接口的对象，所有关联的视图都将自动可用，并且所有此类 URL 都将自动有效。如果您考虑一下，它比 URL 是硬编码的单个 python 文件或 XML 文件强大得多。我对 DJango 和 J2EE 了解不多，所以不能说它们是否具有同等的能力。在不同的皮肤下。这样，可以在不同的皮肤中实现不同的身份验证机制。在主皮肤中，如果身份验证失败，将重定向到不同的登录页面。对于 AJAX 页面，人们可以简单地收到一个 HTTP 错误。这可以集中完成。Zope 3 对象具有接口，并且可以为多个接口定义一个视图。无论您有一个支持给定接口的对象，所有关联的视图都将自动可用，并且所有此类 URL 都将自动有效。如果您考虑一下，它比 URL 是硬编码的单个 python 文件或 XML 文件强大得多。我对 DJango 和 J2EE 了解不多，所以不能说它们是否具有同等的能力。在不同的皮肤下。这样，可以在不同的皮肤中实现不同的身份验证机制。在主皮肤中，如果身份验证失败，将重定向到不同的登录页面。对于 AJAX 页面，人们可以简单地收到一个 HTTP 错误。这可以集中完成。Zope 3 对象具有接口，并且可以为多个接口定义一个视图。无论您有一个支持给定接口的对象，所有关联的视图都将自动可用，并且所有此类 URL 都将自动有效。如果您考虑一下，它比 URL 是硬编码的单个 python 文件或 XML 文件强大得多。我对 DJango 和 J2EE 了解不多，所以不能说它们是否具有同等的能力。可以在不同的皮肤中实现不同的身份验证机制。在主皮肤中，如果身份验证失败，将重定向到不同的登录页面。对于 AJAX 页面，人们可以简单地收到一个 HTTP 错误。这可以集中完成。Zope 3 对象具有接口，并且可以为多个接口定义一个视图。无论您有一个支持给定接口的对象，所有关联的视图都将自动可用，并且所有此类 URL 都将自动有效。如果您考虑一下，它比 URL 是硬编码的单个 python 文件或 XML 文件强大得多。我对 DJango 和 J2EE 了解不多，所以不能说它们是否具有同等的能力。可以在不同的皮肤中实现不同的身份验证机制。在主皮肤中，如果身份验证失败，将重定向到不同的登录页面。对于 AJAX 页面，人们可以简单地收到一个 HTTP 错误。这可以集中完成。Zope 3 对象具有接口，并且可以为多个接口定义一个视图。无论您有一个支持给定接口的对象，所有关联的视图都将自动可用，并且所有此类 URL 都将自动有效。如果您考虑一下，它比 URL 是硬编码的单个 python 文件或 XML 文件强大得多。我对 DJango 和 J2EE 了解不多，所以不能说它们是否具有同等的能力。人们可以简单地收到一个 HTTP 错误。这可以集中完成。Zope 3 对象具有接口，并且可以为多个接口定义一个视图。无论您有一个支持给定接口的对象，所有关联的视图都将自动可用，并且所有此类 URL 都将自动有效。如果您考虑一下，它比 URL 是硬编码的单个 python 文件或 XML 文件强大得多。我对 DJango 和 J2EE 了解不多，所以不能说它们是否具有同等的能力。人们可以简单地收到一个 HTTP 错误。这可以集中完成。Zope 3 对象具有接口，并且可以为多个接口定义一个视图。无论您有一个支持给定接口的对象，所有关联的视图都将自动可用，并且所有此类 URL 都将自动有效。如果您考虑一下，它比 URL 是硬编码的单个 python 文件或 XML 文件强大得多。我对 DJango 和 J2EE 了解不多，所以不能说它们是否具有同等的能力。如果您考虑一下，它比 URL 是硬编码的单个 python 文件或 XML 文件强大得多。我对 DJango 和 J2EE 了解不多，所以不能说它们是否具有同等的能力。如果您考虑一下，它比 URL 是硬编码的单个 python 文件或 XML 文件强大得多。我对 DJango 和 J2EE 了解不多，所以不能说它们是否具有同等的能力。
ZODB 是一个 OO 风格的数据库，不需要模式定义。您可以简单地创建（几乎）所有类型的对象，并将它们持久化。
TTW 有时很烦人，但您可以使用 webdav 挂载 ZOPE-object-tree。然后，您可以使用您喜欢的编辑器编辑模板和脚本。
ZOPE 在创建类似 CMS 的系统方面特别强大，恕我直言，它仍然是无与伦比的——你必须经历很多才能让它在 Django 中同样好用。
并且通过 TTW，实际上像设计师这样的非开发人员有很好的机会开发例如模板和 CSS，而无需开发人员交互。
上面小麦的回答+1：“Zope 2 真的只有从历史的角度学习才有趣”。我为一个大型网站做了几年的 Zope 开发，50% 的 zope 2，50% 的 zope 3。即使在那时（这是 2 年前），我们也在努力将所有东西从 zope 2 迁移出来。除非你已经有很多投资了现有的 Zope 2 项目，没有理由使用它；那里没有太多的未来。如果您确实有一个现有的大型 zope 2 项目，我建议您看一下名为Five（一个笑话：2 + 3 = 5）的产品，旨在
允许您将 Zope 3 技术集成到 Zope 2 中。除此之外，它允许您使用 Zope 3 界面、基于 ZCML 的配置、适配器、浏览器页面（包括皮肤、层和资源）、基于模式的自动添加和编辑表单，对象事件，以及 Zope 3 风格的 i18n 消息目录。
总而言之，Zope 3 是一个与 2 非常不同的框架，恕我直言，一个更好（尽管更复杂）的框架。TTW 是可选的，不建议在大多数情况下使用。隐式获取已经消失。
看起来这里的人已经涵盖了您可能想要使用 ZODB 的原因，所以我想我会提到关于 Zope 3（或使用五的 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 的书绝对是您开始的地方。
