питон фреймворк большой проект

Question

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

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

Будет ли ОРМ полезен?

Answer 1

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

Answer 2

Да. ORM имеет важное значение для сопоставления материала SQL с объектами.

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

1. Использование чужого ORM

2. Ролл свой собственный.

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

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

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

Answer 3

Требования к новым требованиям Alwasy.

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

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

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

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

Answer 4

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

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

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

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

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

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

И последнее, но не менее важное: я не уверен, что вы начинаете хорошую основу для своего проекта. 500 таблиц на любой инфраструктуре python напугают меня до смерти. Скучный, но жесткий язык, такой как java (hibernate + spring + tapestry или около того), кажется более подходящим.

Answer 5

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

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

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

Answer 6

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

Выбрав «raw psycopg2» или SQLAlchemy как технологию для моего уровня доступа к данным, это исключило бы Django (что по моему опыту работает только с его собственным ORM), но это не подходит для проекта такого DB сложности, IMNSHO). Я бы пошел с Werkzeug, лично, в качестве основы, наиболее подходящей для очень сложных проектов, требующих нелепой гибкости и мощности - хотя Pylons и Turbogears 2 поверх нее могут быть приемлемы как неудача, если команда просто не делает " у вас есть опыт работы с веб-приложениями и навыки, необходимые для создания действительно прекрасной музыки с гибкой структурой, такой как Werkzeug.

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

Answer 7

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

ymmv!