Это краткое сравнение фреймворков Python Django и Пирамида была написана Кодементор Шина , который работает с Python в течение 6 лет и в настоящее время участвует в создании инструментов, которые делают hadoop более полезным.
Вступление
Много работая как в Django, так и в Pyramid, я склоняюсь в пользу Pyramid. Но это не самое подходящее все время. Вот небольшое обобщение различий между двумя популярными фреймворками, чтобы помочь вам решить, какой из них подходит для вашей работы.
приступая к работе
Если вы хотите как можно быстрее перейти от нуля к герою, то Django-это фреймворк для вас. Кривая обучения не такая крутая, как пирамида, также книга Django (официальный мега-учебник Django) – замечательная вещь. Впервые я услышал о Джанго, когда впервые услышал о Питоне. Мой опыт работы в качестве нуба с Джанго был по большей части довольно хорошим – он очень дружелюбен к нубу. Начать работу с Пирамидой немного сложнее, но на то есть веские причины.
Гибкость
Пирамида выигрывает этот раз на мили.
Для создания полезного веб-приложения вам понадобится фреймворк, который может связать воедино ряд компонентов (это не исчерпывающий список): система визуализации шаблонов, способ подключения к базе данных, способ сопоставления URL-адресов с представлениями, какая-то система аутентификации и множество других вещей. Пирамида хороша тем, что все эти компоненты можно поменять местами. У вас есть свой выбор механизмов рендеринга шаблонов; у вас есть два разных способа сопоставления URL-адресов с представлениями, и вы можете использовать их оба в одном приложении; вы можете использовать любой метод подключения к базе данных (хотя обычно используется SQLAlchemy) и даже можете подключаться к нескольким базам данных очень разных типов.
С пирамидой вы можете начать с чего – то действительно голого и наращивать все, что вам нужно. Вот действительно простое приложение для пирамиды. Он работает, он служит, он довольно бесполезен, но он самодостаточен.
from wsgiref.simple_server import make_server
from pyramid.config import Configurator
from pyramid.response import Response
def hello_world(request):
return Response('Hi there')
def main():
config = Configurator()
config.add_route('hello', '/') # url dispatch
config.add_view(hello_world, route_name='hello')
app = config.make_wsgi_app()
return app
if __name__ == '__main__':
app = main()
server = make_server('0.0.0.0', 6547, app)
print ('Starting up server on http://localhost:6547')
server.serve_forever()
С другой стороны, у Django есть своя собственная система рендеринга шаблонов, свой собственный ORM (object relational manager – используется для работы с базами данных), свой собственный в основном все. Это действительно делает кривую обучения немного более удобной для новых разработчиков, так как есть гораздо меньше вариантов, но у нее определенно есть свои минусы.
Интерфейс администратора
Одной из убийственных особенностей Django является его интерфейс администратора. Это позволяет очень легко создавать сайт администрирования прямо из моделей приложения. Если в этом нет смысла, я нарисую тебе картинку:
Допустим, у вас есть веб-приложение, которое вы используете для отслеживания всех цветных карандашей в своей жизни. Да, карандаши. Каждый карандаш имеет множество атрибутов, таких как цвет, марка, длина, обхват, острота. Каждый карандаш живет в пенале. Каждый пенал имеет свой цвет и размеры. Каждый пенал находится в комнате в вашем кривом маленьком доме, у каждой комнаты есть имя и логическое значение, указывающее, можем ли мы рисовать на ее стенах. Таким образом, это дает нам 3 разные таблицы базы данных и несколько связей внешних ключей между ними. Если это последнее утверждение не имеет смысла, то в какой-то момент вы, возможно, захотите немного почитать о SQL. Если вы заинтересованы в этом учебнике, SQL, вероятно, будет полезен вам в любом случае.
Итак, мы придумали, какие таблицы нам нужны, и мы пишем некоторые модели (классы, представляющие таблицы, чтобы мы могли дружелюбно взаимодействовать со строками базы данных. Поиск ORM, если вам нужна какая-то информация здесь). Следующий шаг – сделать кучу представлений-нам нужно будет управлять комнатами (добавлять, редактировать); управлять пеналами (добавлять, удалять, редактировать); управлять мелками (добавлять, удалять, редактировать); и управлять отношениями между этими элементами. Кажется, в этом много повторений. Вот в чем суть: если бы вы писали это в Django, вам не нужно было бы писать весь этот код! Джанго достаточно умен, чтобы собрать его для вас. Это может значительно сэкономить время.
Django не делает все за вас – вам нужно сказать ему, какая из ваших моделей должна быть доступна через интерфейс администрирования. У вас также есть некоторый контроль над тем, как ваши модели превращаются в формы и тому подобное, указывая такие вещи, как типы полей и значения по умолчанию. Вот некоторый код для создания модели и добавления ее в интерфейс администрирования:
class Room(models.Model):
name = models.CharField(max_length=30)
can_draw_on_walls = models.BooleanField()
admin.site.register(Room)
Обратите внимание, что этот код очень минимален, интерфейс администратора может делать много вещей и быть настроен всевозможными способами. Тем не менее, настройка интерфейса администратора может занять много времени, поэтому, если вы хотите что-то очень необычное, то Django и Pyramid на самом деле связаны в этом вопросе.
Простота использования
Пирамида выигрывает в этом. Использование декораторов и представлений XHR позволяет очень легко получать запросы AJAX, чтобы идти туда, куда вы хотите. Объяснение XHR, декораторов или AJAX выходит за рамки этого урока, но я уверяю вас, что объяснения есть.
В пирамиде, чтобы добавить маршрут xhr, вы можете сделать что-то вроде этого:
config.add_route('test', '/test', my_view, renderer="json", xhr=True)
Или это:
@view_config(... xhr=True)
Если это не имеет смысла, не волнуйтесь. Если вы решите пойти с пирамидой, то это будет выглядеть довольно просто, как только вы войдете в ситуацию.
У Django нет сопоставимого механизма xhr.
Макет кода
Django использует вещи, называемые приложениями , чтобы упростить подключение новых возможностей к вашему продукту. Это очень хорошо в некотором смысле, потому что это побуждает разработчиков писать самодостаточный код. Это также делает включение приложений из других источников довольно простым и облегчает чтение кода других людей. Django имеет механизм начальной загрузки для создания новых приложений в рамках проекта.
python manage.py startapp books
Эта команда создает новое приложение с именем books в рамках текущего проекта. После создания приложения его необходимо установить, то есть проект должен быть обновлен, чтобы он “знал” о новом приложении. Это делается путем обновления файла настроек проекта. Если это не имеет для вас смысла, я снова отсылаю вас к книге Джанго.
Пирамида, с другой стороны, позволяет вам делать все, что вы хотите, но имеет несколько условностей. Так что это и “за”, и “против”. Соглашения о компоновке кода пирамиды в значительной степени поощряются за счет использования scaffolds , своего рода механизма начальной загрузки. При запуске нового проекта пирамиды вы можете либо создать все свои файлы с нуля (что вряд ли когда-либо стоит времени), либо создать базовый проект для работы с помощью каркаса. Существует несколько различных стандартных каркасов: каркас alchemy оптимизирован для SQLAlchemy, а каркас zodb-для ZODB. Существуют также различные строительные леса, доступные для загрузки. Для создания нового проекта с использованием каркаса мы используем created из командной строки. Вот так:
pcreate -s alchemy hello_alchemy
Это создает проект, в котором есть все необходимые элементы для создания приложения пирамиды на основе SQLAlchemy, и называет приложение hello_alchemy.
Таким образом, Джанго здесь довольно строг, а Пирамида-нет. Django заставляет вас придерживаться определенных соглашений, которые могут сбить с толку новых программистов; и они дают вам возможность выбрать, каких соглашений вы хотели бы придерживаться (что также может сбить с толку новых программистов). Подход пирамиды здесь является еще одним выражением гибкости, которую она обеспечивает.
Поддержка SQLAlchemy
SQLAlchemy-очень мощная вещь, многие очень умные люди думают, что это лучшая РУКА. Если вы выберете Django, вы решите не использовать SQLAlchemy. Это имеет большое значение только в том случае, если ваше приложение очень интенсивно использует базу данных (SQL) – если вы хотите выполнять сложные запросы разумным способом. С другой стороны, если ваше приложение простое, то SQLAlchemy не будет большой помощью, но это не повредит.
Сообщество и поддержка
Это галстук. Сообщества, которые используют и поддерживают как Pyramid, так и Django, огромны.
Вывод
Лично я предпочитаю пирамиду – гибкость, которую она обеспечивает, очень привлекательна и делает работу с ней довольно увлекательной. Но есть определенные причины использовать вместо этого Django. Эти две структуры заслуживают и имеют огромное количество последователей. Довольно трудно сказать, какой из них лучше. Они были разработаны с аналогичными конечными целями и заполняют одну и ту же нишу, но их различные философии очевидны почти в каждом аспекте их соответствующих проектов. Пирамида великолепна, потому что она гибкая, а Django великолепен из-за своей батареи включены философия.