Django против других веб-фреймворков Python?

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

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

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

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


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

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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

Ответ 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, которые могут помочь вам хорошо масштабироваться. Новые официальные документы имеют гораздо лучшее качество, чем старые wiki-документы, на которые вы, похоже, смотрели.

Ответ 5

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

С CherryPy у вас есть выбор во всем. (Рамка шаблона, ORM, если требуется, back-end и т.д.)

Ответ 6

Узнать WSGI

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

def application(environ, start_response) pass

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

Возвращаемое значение - это тело веб-сайта.

def application (environ, start_response):   start_response ( "200 OK", [])   return "..."

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

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

Какую структуру вы используете (CherryPy, Django, TurboGears и т.д.) в основном являются личными предпочтениями. Играйте в каждом, смотрите, что вам больше всего нравится, а затем используйте его. Существует вопрос StackOverflow (с большим ответом) о это, "Рекомендация для прямолинейных фреймворков python"

Ответ 7

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

Ответ 8

Я бы сказал, что правильный ответ зависит от того, чего вы действительно хотите и чего хотите, поскольку то, что будет стоить в долгосрочной перспективе, зависит от того, что вам нужно в долгосрочной перспективе. Если ваша цель - обеспечить развертывание приложений ASAP, тогда это "более простой" маршрут, т.е. Джанго, конечно, путь. Значимость хорошо протестированной и хорошо документированной системы, которую вы хотите, не может быть недооценена.

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

Ответ 9

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

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

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

Ответ 10

Пилоны - отличный инструмент для меня:

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

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

Ответ 11

Я поклонник TurboGears, и это именно то, почему: очень хороший компромисс между контролем и ведением дел прямо и просто.

Разумеется, вам нужно будет составить свой разум. Может быть, вы предпочтете меньше учиться, может быть, больше. Может быть, области, которые мне нравятся, знание/контроль (например, база данных), вам все равно. И не поймите неправильно. Я не отношусь к какому-либо фреймворку как к обязательному или неправильному. Это просто мое субъективное суждение.

Также я бы рекомендовал TurboGears 2, если это вообще возможно. Когда он выйдет, я думаю, что он будет намного лучше, чем 1,0 с точки зрения того, что он выбрал для значений по умолчанию (genshi, pylons, SqlAlchemy)

Ответ 12

Я бы предложил для TurboGears 2. Они сделали фантастическую работу по интеграции лучшего мира Python.

WSGI: Предполагая, что вы разрабатываете умеренно сложные проекты/бизнес-решения в TG2 или в какой-то другой структуре, скажите Grok. Несмотря на то, что эти рамки поддерживают WSGI, это означает, что тот, кто использует эти рамки, должен изучить WSGI? В большинстве случаев ответ - нет. Я имею в виду, что это хорошо.

Знание WSGI, вероятно, более полезно в таких случаях, как

  • вы хотите использовать некоторое промежуточное программное обеспечение или какой-либо другой компонент, который не предоставляется как часть стандартного стека, например. Authkit с TG или Grok без ZODB.
  • вы выполняете некоторую интеграцию.

CherryPy хорош, но подумайте о том, как обрабатывать вашу базу данных, совершать/откатывать в конце транзакций, подвергать json, проверять в таких случаях. TG, Django-подобные фреймворки делают все это для вас.

Ответ 13

Web2py - секретный соус здесь. Не пропустите проверку.