веб-фреймворк Python большой проект

Question

Мне нужны ваши советы, чтобы выбрать Python Web Framework для разработки большого проекта:

База данных (Postgresql) будет иметь не менее 500 таблиц, большинство из которых с составным первичным ключ, множество ограничений, индексы и запросы. Около 1500 просмотров для начала. Проект относится к финансовой сфере. Всегда появляются новые требования.

Поможет ли ORM?

Answer 1

Django использовался многими крупными организациями (Washington Post и т. Д.) И может достаточно легко соединяться с Postgresql Я использую его довольно часто, и у меня не было никаких проблем.

Answer 2

Да. ORM необходим для отображения объектов SQL на объекты.

У вас есть три варианта.

1. Используйте чужую ORM

2. Раскатайся.

3. Попробуйте выполнить низкоуровневые SQL-запросы и выберите нужные поля из набора результатов. Это - на самом деле - своего рода ORM с отображениями, разбросанными по приложениям. Он может быть быстрым и казаться простым в разработке, но это кошмар обслуживания.

Если вы сначала разрабатываете таблицы, любая ORM будет болезненной. Например, «составной первичный ключ», как правило, плохая идея, а с ORM это почти всегда плохая идея. Вам понадобится суррогатный первичный ключ. Тогда вы можете иметь все составные ключи с индексами, которые вы хотите. Они просто не будут «первичными».

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

Answer 3

Поскольку большинство ваших таблиц имеют составные первичные ключи, вам понадобится ORM, который поддерживает эту функцию. ORM по умолчанию в Django не поддерживает составные первичные ключи. SQLAlchemy имеет такую ​​поддержку (http://www.sqlalchemy.org/features.html).

Платформа TurboGears использует SQLAlchemy в качестве ORM по умолчанию. Pylons также позволяет использовать SQLAlchemy.

Есть также способы заставить Django использовать SQLAlchemy, хотя я сам не пробовал их. Я предпочитаю использовать Django самостоятельно, но учитывая ваши потребности, я бы предпочел использовать Pylons или TurboGears, а не вводить в систему другой ORM.

Answer 4

Для такой ужасной сложности уровня данных, как 500 таблиц с 1500 представлениями, в отличие от большинства ответов, я лично предпочел бы придерживаться SQL (PostgreSQL предлагает действительно отличную реализацию, особенно в новой версии 8.4, которую вы должны действительно лоббировать ибо если у вас есть шанс); единственный ORM, который я бы [неохотно] принял, - это SQLAlchemy (один из немногих ORB, которые мне не особо нравятся, но главное добавленное значение - это переносимость на разные СУБД: если вы поддерживаете только одну, и в проекте С этой сложностью БД вам лучше быть, тогда, по моему личному мнению, любая ORM - это просто накладные расходы, поскольку разработчикам уровня доступа к данным потребуется глубокое знакомство с конкретной СУБД для ползания к приемлемой производительности).

Выбрав «raw psycopg2» или SQLAlchemy в качестве технологии для моего уровня доступа к данным, это исключило бы Django (который по моему опыту хорошо работает только с собственным ORM - но это не подходит для проекта такой БД сложность, ИМНШО). Лично я бы пошел с Werkzeug, как с фреймворком, наиболее подходящим для очень сложных проектов, требующих невероятного количества гибкости и мощности - хотя Pylons и Turbogears 2 на вершине этого могут быть приемлемы как запасной вариант, если команда просто не ' не имеет опыта работы с веб-приложениями и навыков, необходимых для создания по-настоящему красивой музыки с помощью гибкой среды, такой как Werkzeug.

И последнее, но не менее важное: я настоятельно рекомендую Dojo создать презентационный уровень на клиенте - богатую и хорошо структурированную инфраструктуру Javascript, предлагающую великолепно разработанную функциональность для «локальных данных», доступа к хосту и т. Д., Оптимизированную для Лучшее, что может предложить каждый из нескольких браузеров (и плагинов, таких как Gears), а также расширенные функциональные возможности пользовательского интерфейса, кажется наиболее вероятным для облегчения тяжелого бремени разработки для серверной части (на самом деле, я настоятельно рекомендую взглянуть на предлагая по существу RESTful-интерфейс на стороне сервера, и делегируйте всю работу над презентациями Dojo на клиенте - см. этот сайт , за исключением того, что я бы подумал о JSON, а не XML как о предпочтительном формате обмена ). Но я с готовностью признаю, что знаю гораздо меньше об аспектах пользовательского интерфейса, чем о бэкэндах, бизнес-логике и общей архитектуре, так что возьмите этот последний абзац во что бы то ни стало! -)

Answer 5

В зависимости от того, что вы хотите сделать, на самом деле у вас есть несколько возможных структур:

[Django] Большой, сильный (до предела того, каким может быть фреймворк Python) и старше в гонке. Используется несколькими «большими» сайтами по всему миру ([сайты Django]). Тем не менее, это немного излишне для почти всего и с устаревшим подходом к кодированию.

[Turbogears] - это новейшая структура, основанная на пилонах. Не знаю много об этом, но получил много хороших отзывов от друзей, которые попробовали это.

[Pylons] (на которых основан Turbogears2). Часто встречающийся на «PHP of Python», он позволяет очень быстрые разработки с нуля. Даже если это может показаться неподходящим для больших проектов, зачастую это более быстрый и простой способ.

Последний вариант - [Zope] (с или без Plone), но Plone слишком медленный, а кривая обучения Zope слишком длинная (даже не говоря о замене ZODB соединителем SQL), так что если вы не пока не знаю основы, просто забудь об этом.

И да, ORM кажется обязательным для проекта такого размера. Для Django вам нужно будет выполнить миграцию на их модели баз данных (не знаю, насколько сложно подключить SQLAlchemy к Django). Для турбогенераторов и пилонов наиболее подходящим решением является [SQLAlchemy], который на самом деле является наиболее полной (и растущей) ORM для python. Для Zope ... ну, неважно

И последнее, но не менее важное: я не уверен, что вы положили начало хорошему проекту. 500 таблиц на любом фреймворке Python напугали бы меня до смерти. Скучный, но жесткий язык, такой как Java (Hibernate + Spring + Tapestry или около того), кажется действительно более подходящим.

Answer 6

Я бы абсолютно рекомендовал Repoze.bfg с SQLAlchemy для того, что вы описываете. Я делал проекты сейчас в Django, TurboGears 1, TurboGears 2, Pylons и баловался чистым Zope3. BFG - это, несомненно, платформа, наиболее предназначенная для размещения проекта, развивающегося так, как вы не ожидали в начале, но гораздо более легкого и урезанного, чем Grok или Zope 3. Кроме того, документы являются лучшими техническими документами из всех из них не 1001 * самый простой , а те, которые отвечают на трудные вопросы, с которыми вы столкнетесь лучше всего. В настоящее время я делаю аналогичную вещь, когда мы переделываем несколько унаследованных баз данных в новое веб-приложение, и мы используем BFG, некоторые Pylons, адаптеры Zope 3, Genshi для шаблонов, SQLAlchemy и Dojo для внешнего интерфейса. Мы не могли бы быть счастливее с BFG, и это отлично работает. Классы BFG как представления, которые на самом деле являются мульти-адаптерами zope, абсолютно идеальны для возможности переопределения только очень специфических битов для определенных ресурсов домена. А полное отсутствие магических глобализаций в любом месте делает тестирование и упаковку самыми простыми, какие у нас были с любой платформой.

YMMV!

Answer 7

Всегда появляются новые требования.

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

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

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

Другим выбором для ORM является SQLAlchemy , который выглядит немного более зрелым из коробки.