从Django视角理解Zope内部结构

8 投票
6 回答
3135 浏览
提问于 2025-04-15 15:50

我刚接触zope,之前在Django上工作了大约2.5年。所以当我第一次接触Zope(版本2)时(只是因为我新公司用了它已经7年了),我遇到了这些问题。请帮我理解一下。

  1. zodb的“真正”目的是什么?我知道它的功能,但能不能告诉我zodb有什么特别之处,是像Django这样的框架所没有的?

    更新:根据回答,Zodb可以替代ORM的需求。你可以直接把对象存储在数据库里(就是zodb本身)。

  2. 有人说zope的一个杀手级特性是TTW(通过网络开发或使用ZMI开发)理念。但我(以及任何开发者)更喜欢基于文件系统的开发(使用版本控制、使用Eclipse、使用任何喜欢的工具在Zope之外)。那么TTW到底在哪里用呢?

  3. 这是个大问题。Zope的获取(Acquisition)相比于Python/Django的继承,究竟有什么“额外的东西”?

  4. 从Django转到Zope真的好吗?

  5. 有没有类似djangosnippets.org的网站可以给Zope(版本2)使用?

6 个回答

7

我对这两个东西的经验不多,但我有机会接触过,所以可以分享一下我对你一些问题的看法。

1) zodb的“真正”目的是什么?我知道它的功能,但能不能告诉我zodb做的一件很棒的事情,而像django这样的框架(没有zodb)却做不到?

通过ZEO进行负载分配和通过ZCatalog进行搜索。就这方面来说,Django的功能比较基础。如果想实现同样的功能,你得重新做很多事情,这就像是重新发明轮子。我很快就学到了一点:别去碰底层数据库的问题。你会搞砸的。这就像打开了一个麻烦的盒子,像沙丘一样麻烦

那么为什么选择django的ORM呢?你还得考虑一下YAGNI。Django是简单且自成体系的,文档也非常好。而当(如果)你的网站发展到一定程度时,你可以再切换到更好的ORM(或者直接用OODB,比如ZODB)。

2) 有人说zope的一个杀手级特性是TTW(通过网络开发或使用ZMI开发)理念。但我(以及任何开发者)更喜欢基于文件系统的开发(使用版本控制,使用Eclipse,使用任何喜欢的工具在Zope之外)。那么这个TTW实际上在哪里用到呢?

我不能很准确地回答这个问题,但我不会说用这种方式开发就根本不好。当然,这是一种思维方式的转变,我自己也倾向于基于文件系统的开发。

4) 从Django转到Zope真的好吗?

Zope 3是非常模块化的,所以你可以自由地从Django中使用它的许多组件。不过,我不太建议这样做。你当然可以,但我发现最大的问题是缺乏帮助。使用zope组件和Django的人不多。迟早你会遇到问题,而谷歌可能帮不了你。到那时,你会意识到如果你的生活是一款视频游戏,你绝对是在困难模式下玩(如果你不得不深入研究zope的代码,可能是极难模式)。

10

关于ZODB:

想要了解“ZODB的真正目的是什么?”可以换个问法:“ZODB最初是为了什么而创建的?”

答案是,这个项目大约在1996年就开始了。那时候还没有MySQL或PostgreSQL,miniSQL(一个可以免费使用但不是开源的软件)数据库还在广泛使用,像Oracle这样的商业数据库也很流行。Python提供了pickle模块,可以把Python对象保存到磁盘上,但这种保存方式比较底层,不能支持事务、并发写入和数据复制等功能。而这些正是ZODB所提供的。

今天在Zope中仍然在使用ZODB,因为它运行得很好。如果你对关系型数据库没有任何基础,学习使用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的使用和推广已经不那么常见,因为这样做已经没有意义。磁盘空间便宜,服务器(相对)便宜,还有很多开发工具期望与标准文件系统交互。

获取(Acquisition):

这是个错误。这个功能非常混乱,导致了很多意想不到的事情发生。理论上,获取有一些有趣的想法,但在实践中最好把它扔掉,几乎没有实际用途。

从Django转到Zope:

Zope 3的开发始于2001年。这解决了很多Zope 2的问题。Zope 2仍然在积极维护,这证明了Zope社区的努力,但它已经不算先进了。从历史角度来看,学习Zope 2还是有趣的。

Zope 3最终朝几个不同的方向发展,因此现代的Zope版本最好用Grok、BFG或Bobo来表达。

Grok最接近Zope 3,因此是一个相对较大的框架——在深入其代码库时可能会让人感到有些不知所措。不过,就像Django或其他全栈框架一样,你不需要使用Grok的每一个部分,学习基础并用它创建网页应用是相对简单的。它的“约定优于配置”做得非常好,基于类的视图使得代码比Django的网页应用更紧凑、更清晰。它的URL路由系统非常灵活,但也可以说是过于复杂。

BFG是一个“只为你需要的部分付费”的框架,由长期的Zope开发者Chris McDonough编写。因此,它在精神上更接近Pylons,只包含那些被认为是核心或必要的部分。它也与WSGI配合得很好,只使用了少数核心的Zope包。

Bobo是一个“微框架”。它只是一个路由URL并提供应用的方式。它不使用任何Zope包,因此不严格属于Zope的网页框架家族。但它是由Zope的创始人Jim Fulton编写的,他最初将Zope的发布部分称为“Bobo”。最初的Bobo是在90年代初编写的,它将URL映射到包和模块,因此如果你的源代码布局如下:

mypackage.mymodule.MyClass

你可以有这样的URL:

/mypackage/mymodule/MyClass

这非常不灵活,后来在Zope 2中被复杂的URL遍历所取代。Bobo使用Routes,因此它在简单的URL解析和复杂的URL解析之间找到了一个中间地带——复杂度大致与Django的URL解析机制相当。

16

首先要说的是,现在的zope2版本其实也包含了zope3的内容。如果你看看现代的zope2应用,比如Plone,你会发现它在后台使用了很多“zope 3”(现在叫“zope工具包”,ZTK)。

ZODB的真正目的是什么呢?它是少数几个被广泛使用的对象数据库之一(与关系型SQL数据库不同)。你可以“直接”把所有的Python对象存储在里面,而不需要使用对象关系映射工具。这里没有“select * from xyz”这样的操作。而且在zodb对象上添加一个新属性“直接”就能保存这个变化,真是太方便了!尤其是在你的数据不容易映射到严格的关系型数据库时。如果你能轻松地映射到关系型数据库,那就直接用这样的数据库吧,我在zope项目中用过几次sqlalchemy。

TTW(通过网页开发):我们已经从这个方向回来了。至少,zope2的TTW方式确实有你担心的那些缺点,比如没有版本控制,没有外部工具等等。Plone正在尝试(可以去谷歌搜索“dexterity”)一些漂亮的zope 3方式来进行TTW开发,这些方式仍然可以映射回文件系统。

TTW:zodb让存储各种配置设置变得简单又便宜,所以你通常可以通过浏览器调整很多东西。不过,这其实不算典型的TTW开发。

获取(Acquisition):这是个很方便的技巧,但会导致命名空间污染,算是一把双刃剑。为了提高调试和维护的便利性,我们在大多数情况下尽量不使用它。获取发生在“对象图”内部,可以想象成“zope站点内部的文件夹结构”。如果在三层文件夹下调用“contact_form”,但在中间找不到,它仍然可以找到站点根目录下的“contact_form”。真是双刃剑!

(当然,常规的Python面向对象继承在各处都在发生)。

从django转到zope:对于某些问题来说,这是个很好的主意,但对于其他问题来说就没什么意义了 :-) 其实有不少zope2/plone公司也做过一些django项目,通常是那些99%的内容都在相对简单的SQL数据库中的项目。如果你更关注内容管理,zope(和plone)可能更适合你。

额外提示:不要只关注zope2。zope3的“组件架构”有很多功能,可以用来创建更大的应用(也包括非网页应用)。比如可以看看grok(http://grok.zope.org),这是一个友好的zope打包版本。纯组件架构在django项目中也可以使用。

撰写回答