grok 与 django 比较
grok 有哪些令人惊叹的（双关语）功能使其比 django 更好？ 我如何知道我的项目何时需要 grok+zope，或者可以只使用 django 进行开发？
What are the smashing (pun intended) features of grok that makes it better than django?
how do I know when my project needs grok+zope, or it can just be developed with django ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Zope 是第一个对象发布框架 evah，Zope 社区在以正确的方式做事方面拥有长期的经验。 Zope 2 是第一次尝试，Zope 3 是下一次尝试，现在我们已经进入了第三代 Web 框架，其中包括 Grok、BFG 和 Bobo。
Grok 非常庞大，并且具有更多的可用模块，而这些模块是在安装基础时所没有的（并且它也在减少所需模块数量的过程中，因此占用空间变得更小）。 BFG 和 Bobo 则相反，它们是简约框架，但可以轻松访问 Zope 工具包和 Zope 的所有功能。
尽管 Django 犯了许多与 Zope2 相同的错误，但他们修复这些错误的速度也快得多，所以我完全预计这个讨论的大部分内容在五年内将毫无意义，因为我预计每个 Python Web 框架都使用 WSGI+WebOb+届时，以 Repoze+Deliverance+Buildout 为基础。但即便如此，我也会选择可以使用 Zope 组件架构和 ZODB 的框架，但这不仅包括 Zope 社区制作的框架，还包括 Turbogears 等。也许到那时它也会包括 Django，谁知道呢...:-)
根据项目要求，我今天会选择 Plone（如果他们需要 CMS）、Grok 或 BFG（取决于涉及的开发人员，以及任务的复杂性和预算）。当然，这部分取决于我对 Zope 技术的丰富经验和对 Django 的少量经验，但主要是因为我可以在 Grok 和 BFG 中使用 ZTK 和 ZODB。
YMMV 等等，等等。
Zope was the first object publishing framework evah, and the Zope community has a long experience with Doing Things The Right Way. Zope 2 was the first attempt, Zope 3 was the next attempt, and we are now into the third generation of web frameworks, which includes Grok, BFG and Bobo.
Grok is massive, and has even more modules available that doesn't come when you install the base (and it's in the process of reducing the number of required modules as well, so the footprint gets smaller). BFG and Bobo go the other way around, and are minimalistic frameworks but with easy access to the Zope Toolkit and all the functionalities of Zope.
And although Django is making many of the same mistakes Zope2 did, they are also fixing them much faster, so I completely expect much of this discussion to be moot in five years, because I expect every single Python web framework to use WSGI+WebOb+Repoze+Deliverance+Buildout as a base by then. But even then I'd go for frameworks where I can use the Zope Component Architecture and ZODB, but that includes not only the ones made by the Zope community, but also for example Turbogears. And maybe it will include Django too by then, who knows... :-)
Depending on what the project requirements are I would today go with either Plone (if they need CMS), Grok or BFG (depending on the involved developers, and the complexity of the task and the budget). This is of course partly depending on my large experience with the Zope technologies and my small experience with Django, but mostly because I can use ZTK and ZODB in Grok and BFG.
YMMV, etc, blahblah.
Grok 基本上以一种更易于使用的方式封装了 zope 的所有功能。因此，您确实获得了真正的 python 对象数据库的所有功能（尽管您可以使用 sql 后端）。我假设您了解所谓的“zope 组件架构”的适配器/实用程序/视图。这些使您能够做出可靠的应用程序。如果您以后需要有选择地自定义它，则特别方便。传统上，安全性是 zope（因此也是 grok）的强项。开发和部署完全用鸡蛋（和构建）来处理：根据我的经验，这是一种强大、可靠、可重复且舒适的方式。
如果您有一个应用程序可以使用直接的 sql 表，而无需事后进行太多选择性定制：django 没有任何问题。您必须自己做很多安全工作，因此需要敏锐的眼光。它背后的框架（ORM 和 url 映射器）要少得多，所以你的 python 会感觉更“纯粹和简单”。这也意味着你需要自己做更多的事情。
没有什么可以阻止您有选择地使用 grok 的某些部分： http://pypi.python.org/pypi例如 /grokcore.component 是非常核心的。隔离得很好，因此您无需购买整个 zope 堆栈即可使用它。我很确定你可以在 django 中使用它。 grokcore/zope 组件只是 python 代码。这将为您提供适配器/接口/实用程序。我不知道你在构建什么，所以你必须进行实验。
我建议尝试一下非常有利于 grok 的一件事：zope 的 ZODB 对象数据库。一个好的 ORM（django 的也不错）可以帮助我们摆脱 SQL 数据库的痛苦，但真正的对象数据库只是普通的奢侈:-)
Grok is basically all the power of zope in a way easier to use package. So you do get all the luxury of a real python object database (though you can use an sql backend). And I assume you know about the adapters/utilities/views of the so-called "zope component architecture". Those allow you to make a robust application. Especially handy if you later need to selectively customize it. And security is traditionally a zope (and thus grok) strong point. Development and deployment are handled fully with eggs (and buildout): in my experience this is a robust and reliable and repeatable and comfortable way.
If you have an application that can work with straight sql tables without needing much selective customizing afterwards: nothing wrong with django. You'll have to do much security yourself, so that needs a keen eye. There's much less of a framework behind it (an ORM and a url mapper), so your python will feel more "pure and simple". This also means you need to do more yourself.
There's nothing from stopping you from selectively using parts of grok: http://pypi.python.org/pypi/grokcore.component for instance is very much the core. Pretty well isolated, so you can use it without buying into the whole zope stack. I'm pretty sure you can use that in django. grokcore/zope component is just python code. This gets you the adapters/interfaces/utilities. I don't know what you're building, so you'll have to experiment.
One thing hugely in favour of grok that I'd suggest trying out: zope's ZODB object database. A good ORM (and django's is pretty ok) helps a lot taking the pain out of SQL databases, but a real object database is just plain luxury :-)
我不认为任何框架都旨在具有任何使一个框架比另一个框架“更好”或在某些情况下“需要”的“功能”。相反，Django 和 Grok（或 Pylons 或 Turbogears）之间的区别实际上是方法之一。您可能会发现 Grok 的方法符合您的喜好，或者您可能更喜欢其他方法之一。我怀疑你可以在其中一个方面取得很多成就，而在其他任何一个方面都无法实现。
I don't think any of the frameworks are intended to have any 'features' that make one 'better' than the other, or 'needed' in certain circumstances. Rather, the difference between Django and Grok - or Pylons, or Turbogears - is really one of approach. You may find the approach of Grok to your liking, or you may prefer one of the others. I doubt there is much you can achieve in one of them that you can't in any of the others.