На ZODB:
Еще один способ спросить: «Какова реальная цель ZODB?» это спросить: «Почему ZODB был изначально создан?»
Ответ на этот вопрос заключается в том, что проект был начат очень рано, примерно в 1996 году. Это было до появления MySQL или PostgreSQL, когда все еще широко использовалась база данных miniSQL (бесплатное, но не бесплатное программное обеспечение), или базы данных больших денег, такие как Oracle. Python предоставил модуль pickle для сериализации объектов Python на диск - но сериализация находится на более низком уровне, она не позволяет использовать такие функции, как транзакции, параллельные записи и репликация. Это то, что обеспечивает ZODB.
Он все еще используется сегодня в Zope, потому что работает хорошо. Если у вас нет существующего набора навыков в реальных базах данных, легче научиться использовать ZODB, чем реляционную базу данных. Это также более простые варианты использования, например, если у вас есть сценарий командной строки, который должен хранить некоторую информацию о конфигурации, использование реляционной базы данных означает необходимость запуска сервера базы данных, чтобы просто сохранить немного конфигурации. Вы можете использовать файл конфигурации, но ZODB также работает довольно хорошо, потому что это встраиваемая база данных. Это означает, что база данных работает в том же процессе, что и остальная часть кода Python.
Стоит также отметить, что API, используемый для хранения объектов внутри контейнеров, отличается от Zope 2 и Zope 3. В 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 позволил людям, которые обычно не могли загружать код на сервер с помощью администратора sysadmin, сделать это.
В текстовых редакторах emacs и vi поддерживают ftp-режимы, а Zope 2 может прослушивать порт FTP. Это позволило бы вам разработать код так, чтобы он хранился в ZODB (редактируемый TTW), но обычно этот код редактировали с использованием emacs или vi.
Сегодня в Zope TTW более редко используется или рекламируется, так как больше не имеет смысла это делать. Дисковое пространство дешево, серверы (относительно) дешевы, и есть много инструментов разработчика, которые ожидают взаимодействия со стандартной файловой системой.
Приобретение:
Это была ошибка. Это была очень запутанная особенность, которая привела к множеству неожиданных вещей. Теоретически есть несколько интересных идей для приобретения, но на практике его лучше бросить в мусорное ведро и практически не использовать.
Переезд из Джанго в Зопе:
Работа над Zope 3 началась в 2001 году. Это устранило множество проблем с Zope 2. Сообщество Zope свидетельствует о том, что Zope 2 по-прежнему активно и в хорошем состоянии, но вряд ли является современным. Zope 2 действительно интересно изучать только с исторической точки зрения.
Zope 3 в конечном итоге развивался в нескольких разных направлениях, и поэтому современные воплощения Zope лучше всего выражены в форме Grok, BFG или Bobo.
Grok ближе всего к Zope 3, и, как таковая, является довольно большой платформой - иногда она может быть довольно подавляющей при копании в ее кодовой базе. Однако, так же как Django или любой другой полнофункциональный фреймворк, вам не нужно использовать каждую часть Grok, может быть довольно легко изучить основы и создавать веб-приложения с его помощью. Это соглашение по конфигурации больше не имеет аналогов, и его представления на основе классов дают гораздо более жесткую и, возможно, более чистую базу кода, чем веб-приложение Django. Система маршрутизации URL-адресов чрезвычайно гибкая, но, возможно, чрезмерно сложная.
BFG - это фреймворк "плати только за то, что ты ешь", написанный давним разработчиком Zope Крисом Макдоноу. Как таковой, он ближе к Pylons по духу, где включены только части, которые считаются основными или существенными для каркаса. Это также очень хорошо играет с WSGI. Он использует только несколько основных пакетов Zope.
Бобо - это «микро-фреймворк». Это просто способ маршрутизации URL-адресов и обслуживания приложения. Он не использует никаких пакетов Zope, поэтому не относится строго к семейству веб-фреймворков Zope. Но это было написано создателем Zope, Джимом Фултоном, который первоначально назвал издательскую часть Zope, "Бобо". Оригинальный Bobo, написанный в начале 90-х, отображал URL-адреса на пакеты и модули, поэтому, если ваш исходный код был выложен как:
mypackage.mymodule.MyClass
У вас может быть такой URL, как:
/mypackage/mymodule/MyClass
Что было очень негибко и было заменено URL Traversel в Zope 2, что довольно сложно. Бобо использует Маршруты, так что он является средним звеном между абсолютно простым разрешением URL и сложным разрешением URL - примерно такой же сложности, как и механизм разрешения URL в Django.