我是zope的新手，之前我在Django工作了大约2。5年。因此，当我第一次跳入Zope（第2版）时（仅因为我的新公司7年来一直使用它），我遇到了这些问题。请帮助我理解它们。
zodb的“真正”目的是什么？我知道它的作用，但告诉我zodb做的一件好事，以及像Django（没有zodb）这样的框架错过。
更新：根据答案，Zodb取代了对ORM的需求。您可以直接将对象存储在db（zodb本身）中。
据说zope的杀手功能之一是TTW（通过Web或使用ZMI开发）的理念。但我（和任何开发人员）更喜欢基于文件系统的开发（使用Version控件，使用Eclipse，使用Zope之外的任何喜欢的工具）。那TTW实际上在哪里使用？
这是最重要的一个。与Python / Django继承相比，Zope的获取获得了什么“EXTRA Stuff”。
来自Django的Zope真的是一个很好的举动吗？
任何网站如djangosnippets.org for Zope（v2）？
答案 0 :(得分：15)
首先要做的事情是：当前的zope2版本也包括所有zope3。如果你看看像Plone这样的现代zope2应用程序，你会发现它在引擎盖下使用了很多“zope 3”（现在称为“zope工具包”，ZTK）。
ZODB的真正目的：它是少数几个对象数据库（与关系SQL数据库相对）之一，它们被广泛使用。您可以“只”将所有python对象存储在那里，而无需使用对象关系映射器。引擎盖下没有“选择*来自xyz”。并且在zodb对象上添加一个新属性“just”会持续存在这种变化。豪华！当您的数据无法轻松映射到严格的关系数据库时，尤其方便。如果可以轻松映射它：只使用这样的数据库，我在zope项目中使用了sqlalchemy几次。
TTW：我们已经从那里回来了。至少，TTW的zope2方式确实具有你担心的所有缺点。没有版本控制，没有外部工具等.Plone正在尝试（google for“dexterity”），使用良好的显式zope 3方式进行TTW开发，仍然可以映射回文件系统。TTW：zodb可以轻松便宜地在数据库中存储各种配置设置，因此您通常可以通过浏览器调整很多内容。不过，这并不算作典型的TTW开发。
收购：方便的技巧，虽然它导致巨大的命名空间污染。双刃剑。为了提高可调试性和维护性，我们在大多数情况下都尝试不用。采集发生在“对象图”内部，因此请考虑“zope站点内的文件夹结构”。调用“contact_form”三个文件夹仍然可以找到网站根目录下的“contact_form”，如果在其间找不到它。双刃剑！
（当然，常规的python面向对象的继承发生在各处。）
从django转移到zope：对于某些问题非常好，对其他问题毫无意义:-)相当多的zope2 / plone公司实际上已经为特定项目完成了一些django项目，通常是那些拥有99％的他们的内容在一个相对简单的SQL数据库中。如果你更喜欢内容管理，那么zope（和plone）可能会更好。
附加提示：不要只关注zope2。 Zope3的“组件架构”具有许多用于创建更大应用程序（也非非Web）的功能。例如，查看grok（http://grok.zope.org）以获得友好的打包zope。纯组件体系结构也可以在django项目中使用。
答案 1 :(得分：9)
答案 2 :(得分：6)
我回答没有太多经验，但我有机会操纵两者，所以我可以告诉你我对你的一些问题的看法。
1）zodb的“真正”目的是什么 因此？意思是我知道它的作用， 但告诉我一个伟大的事情zodb 和django这样的框架（哪个 没有zodb）错过了
通过ZEO进行负载分配并通过ZCatalog进行搜索。从这个角度来看，Django的水平很低。要实现同样的目标，你必须重新实现很多轮子，三角形。 我很快就学到的东西是：不要搞乱低级数据库问题。你会搞砸他们。这是一堆蠕虫，Dune sized。
那为什么选择django ORM？您还应该考虑YAGNI。 django 容易且自包含，文档是高级的，当（如果）您的网站增长那么多时，您将切换到更好的ORM（或者在ZODB的情况下切换到纯OODB） ）稍后。
2）据说是zope的杀手之一 功能是TTW（通过网络或 使用ZMI开发哲学。但 我（和任何开发者）更喜欢 基于文件系统的开发（使用 使用Eclipse进行版本控制 Zope之外最喜欢的工具）。然后 TTW实际上在哪里使用？
我无法正确回答这个问题，但我不会说用这种方法开发是根本不好的。当然这是思维方式的改变，我倾向于更喜欢基于文件系统的开发。
4）这真的是一个很好的行动 来自Django的Zope？
Zope 3非常模块化，因此您可以自由使用django中的许多组件。我会建议反对它。当然，你可以，但我发现最有问题的是缺乏帮助。没有多少人同时使用zope组件和django。迟早，你会遇到问题，谷歌也无济于事。在那一点上，你会意识到，如果你的生活是一个电子游戏，你肯定是在难度级别（如果你不得不把你的鼻子放在zope代码中那么极端的话）。
答案 3 :(得分：6)
关于ZODB的一个非常好的参考是ZODB/ZEO programmer's guide。 ZODB不是ORM。它是一个真正的对象数据库Python对象透明地保存在数据库中，而不必担心如何将它们转换为适合数据库的表示。任何pickleable Python对象都可以保存在ZODB中。关系数据库适用于大量平面数据（如员工记录），而ZODB最适合分层数据（通常在Web应用程序中找到）。我个人使用Zope 3作为我的应用程序。我从未做过TTW类型的工作。使用ZODB的最好的部分是我从来不必担心如何保存数据以及当我将软件从一个版本升级到下一个版本时会发生什么变化。例如，如果我向Python类添加一个新属性，我所要做的就是提供一个默认值作为类属性。然后，它将自动可用于使用同一类的先前版本创建的所有对象。删除属性是对现有对象的简单del操作。 BTW，ZODB可以在任何类型的Python应用程序中独立使用，并且不与ZOPE平台耦合。我喜欢这样一个事实，即在处理Python应用程序而不是ZODB时，我不必担心SQL的细节。当然，如果您需要一个数据库服务器，以便您可以运行由同一服务器支持的应用程序的多个副本，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都自动有效。如果你考虑一下，它比一个python文件或XML文件更强大，其中URL是硬编码的。我对DJango和J2EE并不是很了解，所以不能说它们是否具有相同的功能。
答案 4 :(得分：3)
ZODB是一种OO风格的数据库，不需要架构定义。你可以简单地创建（几乎）所有类型的对象，并持久化它们。
TTW有时令人讨厌，但您可以使用webdav挂载ZOPE对象树。然后，您可以使用自己喜欢的编辑器编辑模板和脚本。
ZOPE对于创建类似CMS的系统特别有用，恕我直言，它仍然是无与伦比的 - 你必须经历很多努力才能使它在Django中同样有效。
通过TTW，实际上像设计师这样的非开发人员很有可能开发出像模板和CSS，无需开发人员互动。
答案 5 :(得分：1)
+1关于小麦的回答，上面：“从历史的角度来看，Zope 2真的很有趣”。我为一个大型网站做了Zope dev几年，50％zope 2,50％zope 3.即使那时（这是2年前）我们正在努力将所有东西从zope迁移出来2.除非你已经有很多东西投资于现有的Zope 2项目，没有理由使用它;那里的未来不多。如果你做有一个大的现有zope 2项目，我建议看看一个旨在
允许您集成Zope 3 技术进入Zope 2.其中 其他，它允许您使用Zope 3 接口，基于ZCML的配置， 适配器，浏览器页面（包括 皮肤，图层和资源）， 基于的自动添加和编辑表单 模式，对象事件，以及 Zope 3风格的i18n消息目录。
当所有的话都说完了，Zope 3是一个非常不同的框架，而恕我直言，更好（虽然更复杂）。 TTW为Five，在大多数情况下不推荐使用。隐含的收购已经消失。
看起来这里的人已经说明了为什么你可能想要使用ZODB，所以我想我会提到Zope 3（或Zope 2使用Five）的另一个好处。 Zope有一个非常强大的系统，用于连接不同的应用程序组件，称为 optional （ZCA）。它允许您编写或多或少自主且可重用的组件，并且可以以标准化方式插入组件。我现在主要做Django开发，有时我发现自己错过了ZCA。在Django中，编写可重用组件的能力是有限的，并且是一种特殊的。但是，像Reinout说的那样zope.component（像大多数zope包一样，包括ZODB）在zope框架之外工作，可以在Django项目中使用。
也就是说，ZCA有其缺点，其中之一就是在XML文件中注册组件的繁琐过程;它对我来说总觉得有点像Java-esqe。我真正喜欢Zope Component Architecture的一个原因是它位于zope.component之上，为你做了大量的工作。
所以底线：Zope 2大部分都是死路一条。如果您的雇主愿意接受它，请开始查看Zope 3，或至少五个。我想你会发现Zope 3与Django相比有着陡峭的学习曲线，所以通过Grok来实现它可能是一个好主意，它可以平滑很多Zope 3的粗糙边缘。但是，我认为对于一个包含大量移动部件的非常大或复杂的Web应用程序，我会选择Zope而不是Django（我说这是一个非常喜欢Django的人）。对于较小的项目，Django可能会更快。在这种情况下量化“大”和“小”虽然很难，但可能还需要几千个单词。如果你真的对Zope 3感兴趣，那么Philipp von Weitershausen的Grok http://grok.zope.org/绝对是一个开始的地方。
