Джанго против других веб-фреймворков Python?

Question

Я в значительной степени перепробовал все существующие веб-фреймворки Python, и мне потребовалось много времени, чтобы понять, что фреймворка с серебряными пулями не существует, у каждого есть свои преимущества и недостатки. Я начал с Snakelets и от всего сердца наслаждался возможностью контролировать практически все на более низком уровне без особой суеты, но затем я обнаружил TurboGears , и я использовал его (1.x) с тех пор. Такие инструменты, как Catwalk и веб-консоль, неоценимы для меня.

Но с выходом TurboGears 2, который приносит поддержку WSGI, и после прочтения религиозных дебатов между лагерями Джанго и WSGI я действительно разрываюсь между «делаю это правильно» , например, изучение WSGI, тратить драгоценное время на написание функциональности, которая уже существует в Django и других полнофункциональных интегрированных средах, в отличие от использования Django или некоторой высокоуровневой интегрированной среды, которая делает все для меня. Недостатки последнего, которые я вижу, довольно очевидны:

1. Я ничего не изучаю в процессе
2. Если мне когда-нибудь понадобится что-то сделать на более низком уровне, это будет боль
3. Затраты, необходимые только для базового сайта, который использует аутентификацию, безумны. (ИМО)

Итак, я думаю, что мой вопрос в том, что является лучшим выбором, или это просто вопрос мнения, и я должен смириться с этим и использовать Django, если он достигает того, что я хочу, с минимальными усилиями (я хочу аутентификацию и CRUD интерфейс к моей базе данных)? Я попробовал Werkzeug, Glashammer и друзей, но AuthKit и Repoze меня напугали, а также количество шагов, необходимых для простой настройки базовой аутентификации. Я посмотрел на Pylons, но документации, похоже, не хватает, и при ссылках на простые функции, такие как аутентификация или интерфейс CRUD, различные вики-страницы и документация, казалось, противоречили друг другу, с разными взломами версий и тому подобным.

---

Спасибо С. Лотту за то, что он указал, что я не достаточно ясно. У меня вопрос: что из следующего целесообразно в долгосрочной перспективе, но не больно в краткосрочной перспективе (например, какое-то среднее звено, кто-нибудь?) - изучать WSGI или придерживаться концепции «с батарейками»? Если последнее, я был бы признателен за предложение о том, должен ли я дать Django еще одну попытку, придерживаться TurboGears 1.x или рискнуть в какой-то другой среде.

Кроме того, я пробовал CherryPy, но, похоже, не смог найти достаточно хорошее приложение CRUD, которое я мог бы использовать и сразу же использовать.

Answer 1

религиозные дебаты между лагерями Джанго и WSGI

Казалось бы, вы немного запутались в том, что такое WSGI и что такое Django. Сказать, что Django и WSGI конкурируют, - все равно, что сказать, что C и SQL конкурируют: вы сравниваете яблоки и апельсины.

Django - это фреймворк, WSGI - это протокол (поддерживаемый Django) для взаимодействия сервера с фреймворком. Самое главное, обучение непосредственному использованию WSGI похоже на обучение ассемблеру. Это большой опыт обучения, но на самом деле это не то, что вы должны делать для производственного кода (и не предполагалось).

Во всяком случае, мой совет - выяснить это для себя. В большинстве фреймворков есть упражнение типа «сделай вики / блог / опрос за час». Проведите немного времени с каждым и выясните, какой из них вам больше нравится. В конце концов, как вы можете выбирать между разными фреймворками, если не хотите их опробовать?

Answer 2

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

Некоторый личный опыт: я провел годы, время от времени возясь с Twisted / Nevow, TurboGears и несколькими другими веб-фреймворками Python. Я никогда ничего не заканчивал, потому что код фреймворка постоянно был незавершенным и переписывался подо мной, документация часто отсутствовала или была неправильной, и единственная жизнеспособная поддержка была через IRC (где я часто получал отличные советы, но чувствовал, что навязываю, если я тоже спрашиваю) много вопросов).

Для сравнения: за последние пару лет я выбил несколько сайтов с Джанго. В отличие от моего предыдущего опыта, они на самом деле развернуты и работают. Процесс разработки Django может быть медленным и осторожным, но это приводит к гораздо меньшему количеству битрота и устаревания, а также к документации, которая действительно полезна.

Поддержка аутентификации HTTP для Django наконец-то появилась несколько недель назад, если это то, на что вы ссылаетесь в # 3.

Answer 3

Предлагаю еще раз взглянуть на TG2. Я думаю, что люди не заметили некоторые успехи, которые были сделаны со времени последней версии. Помимо растущего стека утилит WSGI, есть немало специфических для TG2 элементов, которые следует учитывать. Вот несколько основных моментов:

Система администрирования TurboGears - Этот интерфейс CRUD для вашей базы данных полностью настраивается с помощью декларативного класса конфигурации. Он также интегрирован с Dojo для создания бесконечно прокручиваемых таблиц. Проверка на стороне сервера также автоматизирована. Интерфейс администратора использует URL-адреса RESTful и HTTP-глаголы, что означает, что к ним будет легко подключаться программно с использованием отраслевых стандартов.

CrudRestController / RestController - TurboGears предоставляет структурированный способ обработки служб в вашем контроллере. Предоставляя вам возможность использовать стандартизированные HTTP-глаголы, просто расширяя наш RestController. Объедините Sprox с CrudRestController, и вы сможете использовать crud в любом месте вашего приложения с полностью настраиваемыми автоматически генерируемыми формами. TurboGears теперь поддерживает MIME-типы в качестве расширений файлов в URL, поэтому вы можете настроить контроллер для визуализации .json и .xml с тем же интерфейсом, который используется для визуализации html (возвращая словарь из контроллера)

Если вы нажмете на ссылки, вы увидите, что у нас есть новый набор документации, созданный с использованием sphinx, который является более обширным, чем документы прошлого.

С лучшим веб-сервером , ORM и системой шаблонов (s) (выберите свой собственный) под капотом, легко понять, почему TG имеет смысл для людей, которые хотят быстро начать работу и по-прежнему имеют масштабируемость по мере роста своего сайта.

TurboGears часто рассматривается как попытка поразить движущуюся цель, но мы последовательны в отношении выпусков, что означает, что вам не придется беспокоиться о том, чтобы работать из ствола, чтобы получить новейшие функции, которые вам нужны. Будущее: больше расширений TurboGears, которые позволят вашему приложению расширять функциональность с помощью простых команд paster.

Answer 4

Ваш вопрос, кажется, «стоит ли изучать WSGI и делать все самостоятельно» или использовать «интегрированную среду стека, которая сделает все за вас».

Я бы сказал, что это ложная дихотомия, и есть очевидный третий путь. TurboGears 2 пытается обеспечить плавный путь от фреймворка стиля «сделай все для себя» до понимания промежуточного программного обеспечения WSGI и возможность настраивать практически каждый аспект фреймворка в соответствии с потребностями вашего приложения.

Возможно, мы не добьемся успеха в каждом месте на каждом уровне, но особенно если у вас уже есть опыт работы с TurboGears 1, я думаю, что кривая обучения TG2 поначалу будет очень, очень легкой, и у вас будет возможность пройти глубже точно, когда вам это нужно.

Для решения ваших конкретных вопросов:

• Мы предоставляем систему авторизации из коробки, которая соответствует той, к которой вы привыкли в TG1.
• Мы предоставляем готовый интерфейс типа django admin, называемый tgext.admin, который отлично работает с dojo, чтобы сделать модную электронную таблицу, подобную интерфейсу, по умолчанию.

Я также хотел бы рассмотреть пару других вариантов, которые там есть, и немного рассказать о преимуществах.

• CherryPy. Я думаю, что CherryPy - отличный веб-сервер и приятный минималистичный веб-фреймворк. Он не основан на WSGI внутри, но имеет хорошую поддержку WSGI, хотя и не предоставит вам возможности «полного стека». Но для пользовательских настроек, которые должны быть быстрыми и не особенно подходящими для настроек по умолчанию, предоставляемых Django или TurboGears, это отличное решение.

• Django. Я думаю, что Django - очень хорошая, тщательно интегрированная система для разработки веб-сайтов. Если ваше приложение и стиль работы хорошо вписываются в его стандартные настройки, это может быть фантастическим. Однако, если вам необходимо настроить использование вашей БД, заменить язык шаблонов, использовать другую модель авторизации пользователя или иным образом сделать что-то другое, вы, скорее всего, столкнетесь с фреймворком.

• Пилоны Пилоны, такие как CherryPy, - это отличный минималистичный веб-фреймворк. В отличие от CherryPy, он поддерживает WSGI во всей системе и обеспечивает некоторые нормальные значения по умолчанию, такие как SQLAlchemy и Mako, которые могут помочь вам хорошо масштабироваться. Новые официальные документы гораздо лучшего качества, чем старые вики-документы, на которые вы, похоже, смотрели.

Answer 5

Вы смотрели на CherryPy. Это минималистичный, но эффективный и простой. Это достаточно низкий уровень, чтобы не мешать, но достаточно высокий, чтобы скрыть сложность. Если я хорошо помню, TurboGears был построен на нем.

С CherryPy у вас есть выбор всего. (Фреймворк шаблона, ORM, если требуется, серверная часть и т.

Answer 6

Learn WSGI

WSGI абсурдно прост .. Это в основном функция, которая выглядит как ...

def application(environ, start_response) pass

Функция вызывается при получении HTTP-запроса. environ содержит различные данные (например, URI запроса и т. Д.), start_response - вызываемая функция, используемая для установки заголовков.

Возвращаемым значением является тело сайта.

def application (environment, start_response): start_response ("200 OK", []) возврат "..."

Это все, что нужно, на самом деле .. Это не фреймворк, а скорее протокол для использования веб-фреймворками ..

Для создания сайтов использование WSGI не «правильный путь» - использование существующих фреймворков это ... но если вы пишете веб-фреймворк Python, то использование WSGI - абсолютно верный путь

Какой фреймворк вы используете (CherryPy, Django, TurboGears и т. Д.) В основном личные предпочтения. Поиграйте с каждым, посмотрите, что вам больше всего нравится, затем используйте его. this, «Рекомендация для простых структур Python»

Answer 7

Я бы сказал, что правильный ответ зависит от того, что вы на самом деле хотите и в чем нуждаетесь, поскольку то, что будет полезно в долгосрочной перспективе, зависит от того, что вам понадобится в долгосрочной перспективе. Если ваша цель состоит в том, чтобы приложения были развернуты как можно скорее, то «более простой» маршрут, т.е. Джанго, безусловно, путь. Нельзя недооценивать ценность хорошо протестированной и хорошо документированной системы, которая именно то, что вам нужно.

С другой стороны, если у вас есть время, чтобы изучить множество новых вещей, которые могут применяться в других областях, и вы хотите иметь самые широкие возможности для настройки, тогда что-то вроде Turbogears лучше. Turbogears дает вам максимальную гибкость, но вам придется потратить много времени на чтение внешних документов для таких вещей, как Repoze, SQLAlchemy и Genshi, чтобы получить что-нибудь полезное с ним. Документы TG2 намеренно менее подробны, чем документы TG1, в некоторых случаях, потому что считается, что внешние документы лучше, чем они были раньше. Является ли такая вещь препятствием или инвестицией, зависит от ваших собственных требований.

Answer 8

Вы проверили web2py? После недавней оценки многих веб-фреймворков Python я решил принять этот. Также проверьте Google App Engine, если вы еще этого не сделали.

Answer 9

Пилоны кажутся мне отличным инструментом:

• настоящий веб-фреймворк (CherryPy - это просто веб-сервер),
• небольшая кодовая база - повторное использование других проектов,
• написано полностью с учетом WSGI, на основе Paste,
• позволяет сразу же закодировать приложение и при необходимости коснуться битов низкого уровня,

Я использовал CherryPy и TurboGears и смотрел на многие другие фреймворки, но ни одна из них не была настолько легкой и продуктивной, как Pylons. Проверьте презентацию в Google .

Answer 10

Django определенно стоит изучить, и, похоже, он подойдет для ваших целей. Прилагаемый к нему интерфейс администратора прост в настройке и использует аутентификацию.

Что касается "чего-либо более низкого уровня", если вы имеете в виду sql, вполне возможно внедрить sql в ваши запросы с помощью дополнительного ключевого слова. Стилистически вы всегда стараетесь избегать этого как можно больше.

Что касается "ничего не изучать" ... реальный вопрос заключается в том, предпочитаете ли вы в первую очередь изучать что-то более низкого или более высокого уровня, что вряд ли кто-то здесь может ответить за вас.