Грок против Джанго сравнения - PullRequest
7 голосов
/ 01 октября 2009

Каковы отличительные черты grok, которые делают его лучше, чем django? как узнать, когда моему проекту нужен grok + zope, или он может быть разработан с помощью django?

Ответы [ 3 ]

7 голосов
/ 03 октября 2009

Zope был первой платформой для публикации объектов, да и сообщество Zope имеет большой опыт работы с Doing Things The Right Way. Zope 2 была первой попыткой, Zope 3 была следующей попыткой, и теперь мы находимся в третьем поколении веб-фреймворков, которое включает в себя Grok, BFG и Bobo.

Grok огромен и имеет еще больше доступных модулей, которые не появляются, когда вы устанавливаете базу (и она также сокращает количество необходимых модулей, поэтому занимаемая площадь уменьшается). BFG и Bobo работают наоборот и представляют собой минималистичные фреймворки, но с легким доступом к инструментарию Zope и всем функциональным возможностям Zope.

И хотя Django делает многие из тех же ошибок Zope2 делали, они также фиксируя их гораздо быстрее, так что я полностью ожидать большую часть этого обсуждения, спорны в течение пяти лет, потому что я ожидаю каждый Python фреймворк использовать WSGI + WebOb + Repoze + Deliverance + Buildout в качестве базы к тому времени. Но даже тогда я выбрал бы фреймворки, в которых я мог бы использовать Архитектуру компонентов Zope и ZODB, но это включает не только те, что сделаны сообществом Zope, но также, например, Turbogears. И, возможно, к тому времени это будет включать и Джанго, кто знает ...: -)

В зависимости от требований проекта, я бы сегодня выбрал Plone (если им нужна CMS), Grok или BFG (в зависимости от вовлеченных разработчиков, сложности задачи и бюджета). Это, конечно, частично зависит от моего большого опыта работы с технологиями Zope и моего небольшого опыта работы с Django, но главным образом потому, что я могу использовать ZTK и ZODB в Grok и BFG.

YMMV и т. Д., Бла-бла.

5 голосов
/ 01 октября 2009

Grok - это, по сути, вся мощь zope в более удобном для использования пакете. Таким образом, вы получаете всю роскошь реальной базы данных объектов Python (хотя вы можете использовать SQL-сервер). И я предполагаю, что вы знаете об адаптерах / утилитах / представлениях так называемой «архитектуры компонентов zope». Это позволяет сделать надежное приложение. Особенно удобно, если вам позже потребуется выборочная настройка. А безопасность традиционно является сильной стороной Zope (и, следовательно, Grok). Разработка и развертывание полностью осуществляются с использованием яиц (и сборки): по моему опыту это надежный, надежный, воспроизводимый и удобный способ.

Если у вас есть приложение, которое может работать с простыми таблицами SQL, не требуя при этом особой выборочной настройки: ничего страшного в django. Вы должны будете сделать много безопасности самостоятельно, так что для этого нужен острый глаз. За ним гораздо меньше фреймворка (ORM и преобразователь URL), поэтому ваш питон будет чувствовать себя «более чистым и простым». Это также означает, что вам нужно делать больше самостоятельно.

Ничто не мешает вам выборочно использовать части grok: http://pypi.python.org/pypi/grokcore.component, например, является ядром. Довольно хорошо изолированы, так что вы можете использовать их, не покупая весь стек Zope. Я уверен, что вы можете использовать это в Django. Компонент grokcore / zope - это просто код Python. Это дает вам адаптеры / интерфейсы / утилиты. Я не знаю, что вы строите, поэтому вам придется экспериментировать.

Одна вещь в пользу grok, которую я бы предложил опробовать: zope объектная база данных ZODB. Хороший ORM (и django довольно хорошо) очень помогает избавиться от боли в базах данных SQL, но база данных реальных объектов - просто роскошь: -)

2 голосов
/ 01 октября 2009

Я не думаю, что какая-либо из фреймворков имеет какие-либо «функции», которые делают одно «лучше» другого или «необходимо» в определенных обстоятельствах. Скорее, разница между Django и Grok - или Pylons, или Turbogears - действительно является одним из подходов. Вы можете найти подход Grok по своему вкусу, или вы можете предпочесть один из других. Я сомневаюсь, что вы можете достичь многого в одном из них, чего не можете достичь ни в одном другом.

...