从Django eyes了解Zope的内部结构

Question

我是zope的新手，我以前在Django上工作了大约2.5年。所以当我第一次跳进Zope（v2）时（仅仅因为我的新公司7年来就开始使用它），我面临着这些问题。请帮助我理解他们。在

1. zodb的“真正”目的是什么？我知道它做了什么，但是告诉我一件事zodb做得很好，而且像Django这样的框架（没有zodb）没有做到。在

   更新：根据答案，Zodb取代了ORM的需要。您可以直接将对象存储在数据库中（zodb本身）。

2. 据说zope的杀手特性之一是TTW（通过Web或使用ZMI开发）理念。但是我（和任何开发人员）更喜欢基于文件系统的开发（使用版本控制、使用Eclipse、使用Zope之外任何喜欢的工具）。那么这个TTW在哪里实际使用？

3. 这是最大的一个。与Python/Django继承相比，Zope的收购获得了什么“额外的东西”。

4. 从Django来到Zope真的是一个好的举动吗？

5. 任何类似的网站djangsnippets.org网站对于Zope（v2）？

Answer 1

我在回答这两个问题时都没有太多经验，但我有机会操纵这两个问题，所以我可以告诉你我对你的一些问题的看法。在

1)What is the "real" purpose of zodb as such? Meaning 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

通过ZEO进行负载分配，通过ZCatalog进行搜索。从这个角度来看，Django的水平很低。为了达到同样的效果，你必须重新安装很多轮子，三角形的。 我很快就学到了一点：不要处理低级数据库问题。你会把他们搞砸的。这是一罐蠕虫，Dune sized。在

那么为什么选择django ORM呢？您还应该考虑if YAGNI。django非常简单，而且是自包含的，文档是很高级的，当（如果）您的站点增长到这样大的程度时，您将切换到更好的ORM（或者在ZODB的情况下转换到纯OODB）。在

2)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?

我不能正确回答这个问题，但我不想说，用这种方法来发展根本上是不好的。当然，这是思维方式的改变，我也倾向于选择基于文件系统的开发。在

4)Is it really a good move to work on Zope, from Django ?

zope3是非常模块化的，因此您可以自由使用django的许多组件。不过，我还是建议不要这样做。你当然可以，但我发现最大的问题是缺乏帮助。同时使用zope组件和django的人并不多。迟早，你会遇到问题，谷歌也不会帮你。在那一点上，你会意识到如果你的生活是一个视频游戏，你肯定是在玩难度很高的游戏（可能是极端的，如果你必须把你的鼻子投入到zope代码中）。在

Answer 2

第一件事：当前的zope2版本也包括了所有的zope3。如果你看看像Plone这样的现代zope2应用程序，你会发现它在幕后使用了很多“zope3”（现在称为“zopetoolkit”，ZTK）。在

ZODB的真正用途：它是为数不多的被广泛使用的对象数据库（与关系SQL数据库相反）之一。您可以“只”将所有python对象存储在那里，而不需要使用对象关系映射器。引擎盖下没有“从xyz中选择”。在zodb对象上添加一个新属性“只是”保持了这种变化。豪华！尤其是当您的数据无法轻松映射到严格的关系数据库时。如果您可以轻松地映射它：只需使用这样的数据库，我在zope项目中使用过几次sqlalchemy。在

TTW：我们从那回来了。至少，TTW的zope2方式确实有您所担心的所有缺点。没有版本控制，没有外部工具，等等。Plone正在试验（google的“dexterity”），用漂亮的显式zope3方法进行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项目中使用。在

Answer 3

在ZODB上：

另一种问“ZODB的真正目的是什么？”就是问，“为什么ZODB最初是创建的？”在

答案是这个项目很早就开始了，大约在1996年。这是在MySQL或PostgreSQL出现之前，miniql（一种免费使用但不是免费软件）数据库，或是像Oracle这样的大资金数据库。Python提供pickle模块来将Python对象序列化到磁盘上，但是序列化级别较低，它不允许事务、并发写入和复制等特性。这就是ZODB提供的。在

它仍然在Zope使用，因为它工作得很好。如果您在现实数据库中没有现成的技能，那么学习使用ZODB比学习关系数据库更容易。它也可以使用更简单的用例，例如，如果您有一个命令行脚本需要存储一些配置信息，那么使用关系数据库意味着必须运行数据库服务器来存储一点配置信息。但你也可以很好地使用ZODB文件。这意味着数据库与其余的Python代码在同一进程中运行。在

同样值得注意的是，用于在容器中存储对象的API在zope2和zope3之间是不同的。在Zope 2中，容器作为属性存储：

 root.mycontainer.myattr

在Zope 3中，它们使用与Python标准字典类型相同的接口：

^{pr2}$

这是学习使用ZODB比使用Django ORM容易的另一个原因，因为Django有自己的ORM接口，这与Python现有的接口不同。在

通过网络（TTW）：

同样，理解TTW的原因可以追溯到Zope开发的时候。虽然与Subversion或Mercurial等著名的开发工具决裂似乎很愚蠢，但Zope是在90年代末开发的，当时唯一的免费版本控制系统是CVS。Zope2有它自己简单的版本控制功能，它们和CVS一样好（也就是说，“它们很有限，很糟糕”）。当时UNIX工作站的成本要高得多，而且资源也少得多，因此系统管理员对服务器的管理更加谨慎和谨慎。TTW允许那些通常无法通过sysadmin交互将代码上载到服务器的人来实现这一点。在

通过文本编辑器，emacs和vi有ftp模式，zope2可以监听ftp端口。这将允许您进行开发，以便代码存储在ZODB（可编辑的TTW）中，但是使用emacs或vi编辑此代码是很常见的

今天在Zope，TTW很少被使用或推广，因为这样做已经没有意义了。磁盘空间便宜，服务器（相对地）便宜，而且有许多开发工具希望与标准文件系统交互。在

收购：

这是个错误。这是一个非常令人困惑的特性，导致了很多意想不到的事情发生。理论上有一些有趣的想法可以获得，但实际上最好是扔进垃圾箱，实际用处不大。在

从Django到Zope：

2001年，Zope3开始工作。这修复了zope2的很多问题。这证明了Zope社区zope2仍然很活跃并且得到了很好的维护，但是它几乎不是最先进的。从历史的角度来看，Zope2才是真正有趣的。在

Zope3最终在几个不同的方向发展，所以Zope的现代化身最好以Grok、BFG或Bobo的形式表达。在

当Zok的代码非常庞大的时候，它是最接近的。然而，就像Django或任何其他完整的堆栈框架一样，不需要使用Grok的每一部分，学习basi非常容易并用它创建web应用程序。它的约定优于配置是首屈一指的，它基于类的视图给它提供了一个比Django web应用程序更紧凑、更干净的代码库。它的URL路由系统非常灵活，但也可以说是过度设计。在

BFG是一个由长期Zope开发人员chrismcdonough编写的“只为吃的东西付费”的框架。因此，它在精神上更接近于塔架，只包括被认为是框架核心或必不可少的部分。它与WSGI的配合也很好。它只使用了几个核心的Zope包。在

Bobo是一个“微框架”。这只是一种路由网址和提供应用程序的方式。它不使用任何Zope包，因此严格来说它不属于Zope系列的web框架。但它是由Zope的创造者吉姆·富尔顿（Jim Fulton）撰写的，他最初称Zope的出版部分为“Bobo”。最初的Bobo是在90年代早期编写的，它将url映射到包和模块，因此如果您的源代码被布置成：

mypackage.mymodule.MyClass

您可以有一个URL，例如：

/mypackage/mymodule/MyClass

它非常不灵活，在zope2中被URL遍历所取代，这相当复杂。Bobo使用路由，所以它是一个介于简单的URL解析和复杂的URL解析之间的中间地带，其复杂程度与Django的URL解析机制差不多。在