Плюсы и минусы различных подходов к веб-программированию на Python

Ответ 1

CGI отлично подходит для сайтов с низким трафиком, но имеет некоторые проблемы с производительностью для чего-либо еще. Это связано с тем, что каждый раз, когда приходит запрос, сервер запускает приложение CGI в своем собственном процессе. Это плохо по двум причинам: 1) запуск и остановка процесса может занять время и 2) вы не можете кэшировать что-либо в памяти. Вы можете пойти с FastCGI, но я бы сказал, что вам лучше написать прямое приложение

Лично мне не нравятся фреймворки, которые делают для меня слишком много магии и предпочитают технику смешивания и совпадения, но мне сказали, что я тоже совершенно безумный.:)

Сколько у вас опыта веб-программирования? Если вы новичок, я говорю, иди с Django. Если вы более опытные, я говорю, чтобы поиграть с различными подходами и приемами, пока вы не найдете правильный.

Ответ 2

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

В один шаг от этого встроен ваш код Python в ваш HTML-код, например, с PSP. Я не думаю, что многие люди используют это в наши дни, поскольку современные системы шаблонов сделали это довольно устаревшим. Я некоторое время работал с PSP и обнаружил, что он имеет в основном те же организационные ограничения, что и скрипты CGI (каждая страница имеет свой собственный файл), а также некоторые неприятности, связанные с пробелами, из-за попытки смешать непрозрачный HTML-код с незашифрованным Python.

Следующий шаг - это очень простые веб-фреймворки, такие как web.py, которые я также использовал. Как и скрипты CGI, очень просто получить что-то и запустить, и вам не нужна сложная конфигурация или автоматически сгенерированный код. Ваш собственный код будет довольно прост для понимания, поэтому вы можете увидеть, что происходит. Тем не менее, он не настолько богат, как другие веб-фреймворки; в прошлый раз, когда я использовал его, не было сеансового отслеживания, поэтому мне пришлось сворачивать самостоятельно. У него также есть "слишком много магического поведения", чтобы процитировать Guido ( "upvars(), bah" ).

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

В конечном счете вам придется решать, что вы предпочитаете. Например, фреймворки используют языки шаблонов (специальный код/​​теги) для генерации HTML файлов. Некоторые из них, такие как шаблоны Cheetah, позволяют писать произвольный код Python, чтобы вы могли делать что-либо в шаблоне. Другие, такие как шаблоны Django, являются более ограничительными и заставляют вас отделять ваш код презентации от вашей логики программы. Все, что вы лично предпочитаете.

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

Я лично использую сочетание веб-фреймворков, используя CherryPy для моего веб-сервера (параметры формы, обработку сеанса, сопоставление URL-адресов и т.д.) и Django для моего объектно-реляционного сопоставления и шаблонов. Моя рекомендация - начать с веб-фреймворка высокого уровня, проработать свой учебный курс, а затем начать с небольшого личного проекта. Я сделал это со всеми технологиями, о которых я говорил, и это было действительно полезно. В конце концов вы получите представление о том, что вы предпочитаете, и стать лучшим веб-программистом (и лучшим программистом в целом) в этом процессе.

Ответ 3

Если вы решите пойти с фреймворком, основанным на WSGI (например TurboGears), я бы рекомендовал вам пройти отличная статья Еще одна "Сделай сам" . Ian Bicking.

В статье он строит простую структуру веб-приложений с нуля.

Кроме того, посмотрите видео Создание веб-фреймворка с WSGI Кевином Дангуром. Дангор является основателем проекта TurboGears.

Ответ 4

Если вы хотите сделать большой, выберите Django, и вы настроены. Но если вы хотите просто научиться, сворачивайте свою собственную фреймворк, используя уже упомянутый WebOb - это может быть очень весело, и я уверен, Изучите гораздо больше (плюс вы можете использовать компоненты, которые вам нравятся: система шаблонов, диспетчер URL-адресов, уровень базы данных, сеансы и т.д.).

За последние 2 года я построил несколько больших сайтов, используя Django, и все, что я могу сказать, Django заполнит 80% ваших потребностей в 20% случаев. Остальные 20% работы будут занимать 80% времени, независимо от того, какую структуру вы будете использовать.

Ответ 5

Всегда стоит делать что-то трудное - один раз - как упражнение. Как только вы поймете, как это работает, выберите фреймворк, который подходит вашему приложению, и используйте его. Вам не нужно изобретать велосипед, как только вы понимаете скорость angular.: -)

Также стоит убедиться, что у вас есть достаточно надежное понимание языка программирования, лежащего за рамкой, прежде чем вы перейдете к нему - пытаясь одновременно изучить как Django, так и Python (или Ruby и Rails, или X и Y), может привести к еще большей путанице. Сначала напишите код на языке, затем добавьте фреймворк.

Мы учимся развиваться не с помощью инструментов, а путем решения проблем. Бегите в несколько стен, поднимайтесь и находите несколько более высоких стен!

Ответ 6

Если вы никогда не делали каких-либо программ CGI, прежде чем я думаю, что стоит сделать один проект - возможно, только образец игрового сайта только для вас - с использованием подхода DIY. Вы узнаете намного больше о том, как работают все различные части, чем вы, используя фреймворк. Это поможет вам разрабатывать и отлаживать и т.д. На всех ваших будущих веб-приложениях, но вы пишете их.

Лично я теперь использую Django. Настоящая выгода - очень быстрое развертывание приложений. Реляционное сопоставление объектов быстро перемещает вещи, и библиотека шаблонов - это радость в использовании. Также интерфейс администратора дает вам базовые экраны CRUD для всех ваших объектов, поэтому вам не нужно писать какие-либо "скучные" вещи.

Недостатком использования решения на основе ORM является то, что если вы хотите использовать какой-либо SQL-код, например, по соображениям производительности, это намного сложнее, чем в противном случае, хотя это все еще возможно.

Ответ 7

Если вы используете Python, вам не следует начинать с CGI, вместо этого начинайте с WSGI (и вы можете использовать wsgiref.handlers.CGIHandler для запуска своего WSGI script как CGI script. Результатом является то, что в основном такое же низкоуровневое, как CGI (которое может быть полезным в образовательном смысле, но также будет несколько раздражать), но без необходимости писать полностью устаревший интерфейс (и привязка вашего приложения к одной модели процесса).

Если вам нужен менее раздражающий, но аналогично низкоуровневый интерфейс, используя WebOb, это обеспечит это. Вы будете внедрять всю логику, и будет мало темных углов, которые вы не поймете, но вам не придется тратить время на выяснение того, как анализировать даты HTTP (они странные!) Или анализировать тела POST. Я пишу приложения таким образом (без каких-либо других фреймворков), и он полностью работоспособен. Как новичок, я бы посоветовал это, если вам было интересно понять, какие рамки делают, потому что неизбежно вы будете писать свои собственные мини-рамки. OTOH, реальная структура, вероятно, научит вас хорошей практике проектирования и структуры приложений. Чтобы быть действительно хорошим веб-программистом, я считаю, что вам нужно попробовать серьезно; вы должны понимать все, что делает инфраструктура, и не бояться ее внутренних компонентов, но вы также должны тратить время на продуманную среду, которую кто-то другой разработал (т.е. существующую структуру), и понять, как эта структура помогает вам.

Ответ 8

Хорошо, рельсы на самом деле довольно хороши, но там есть немного слишком много волшебства (из мира Ruby я бы предпочел merb для рельсов). Я лично использую Pylons, и я довольно чертовски счастлив. Я бы сказал (по сравнению с django), что пилоны позволяют вам обменивать внутренние части ints легче, чем django. Недостатком является то, что вам придется писать больше всего по себе (например, базовый CRUD).

Плюсы использования рамки:

• быстро сделайте материал (и я имею в виду, что вы быстро знаете, как вы знаете рамки).
• все соответствует стандартам (чего, вероятно, не так легко достичь, когда вы катаетесь самостоятельно).
• легче получить что-то работающее (много учебников), не читая статьи и документы gazillion

Минусы:

• вы узнаете меньше
• сложнее заменить детали (не так много проблем в пилонах, тем более с django)
• сложнее настроить некоторые низкоуровневые вещи (например, вышеупомянутые SQL)

Из этого вы, вероятно, можете придумать, на что они хороши:-) Так как вы получаете весь код, можно настроить его, чтобы он соответствовал даже самым сложным ситуациям (пилоны, предположительно, теперь работают с движком Google...).

Ответ 9

Для небольших проектов, сворачивание собственных довольно просто. Тем более, что вы можете просто импортировать шаблонный движок, например Genshi, и сделать это довольно быстро и легко. Иногда он быстрее использует отвертку, чем искать силовую бурильную машину.

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