Подходит ли дизайн PHP, Python, PostgreSQL для бизнес-приложения?

Я лично согласен со вторым и третьим пунктами вашего поста. Что касается PHP, на мой взгляд, вы можете использовать Python и для презентации, существует множество решений (Zope, Plone ...) на основе Python.

Посмотрите на Джанго.

Код Python. Язык шаблонов, который допускает некоторые из тех же функций, что и PHP, - немного другой синтаксис.

Модель отделена от функций просмотра («бизнес-правил») и от представления. Это применяется во всем Django.

Один из распространенных вопросов: «Почему я не могу сделать - какую-то сумасшедшую PHP-подобную вещь - в шаблоне Django?» Ответ в том, что презентация не обрабатывается. Выполняйте свою обработку в функциях просмотра Django. Отобразите результаты в шаблоне как HTML.

Кроме того, в Django есть уровень ORM, который отвлекает вас от мелких вопросов, связанных с SQL. MySQL или PostgreSQL более или менее эквивалентны внутри Django.

Редактировать

«Зрелость» означает многое. Вы особо упомянули квалифицированных людей как признак зрелости.

Django - это чистый Python. Если вы сможете найти людей, занимающихся Python, они смогут изучить Django за несколько дней. Им просто нужно делать уроки.

• Сайт на базе Django - это обычно Apache + some glue + Django. Клей может быть mod_wsgi, mod_python или mod_fastcgi. Вы должны осторожно управлять этой конфигурацией, потому что в ней есть несколько движущихся частей. Это, однако, та же проблема конфигурации Apache, что и у вас с PHP - здесь нет ничего нового.

• Сайт Django имеет один или несколько экземпляров сервера Django, каждый с файлом настроек, сопоставлением URL-адресов и любым количеством приложений. На данный момент чистый Python.

• Приложение Django имеет сопоставления URL-адресов, модель и представления. Все на чистом Python. Модуль протестирован с расширениями Django для собственной внутренней среды unittest Python.

• Модель использует слой ORM. Возможно, это самая запутанная вещь в Django. Люди иногда создают очень странные модели, потому что думают либо слишком универсально, либо слишком много думают о SQL. Django - это золотая середина в основном объектно-ориентированного программирования с некоторым учетом SQL. Получите это, и вас не остановить.

• Приложение Django может иметь шаблоны, написанные на их собственном языке шаблонов. Это будет единственная вещь, не связанная с Python, которая представляет большой интерес. Вы можете добавить собственные теги - чистый Python.

• У вас, вероятно, будет JavaScript (также верно для PHP и любой другой инфраструктуры веб-приложений). Здесь ничего нового.

• Поскольку приложение администратора Django автоматически обрабатывает базовую обработку CRUD, вам не нужно писать это. Вы можете писать все, что хотите. Но это не обязательно. Это приводит вас к очень и очень мощному гибриду.

  • Вы пишете несколько сложных критических транзакций. Чистый Python, кстати.

  • Вы не пишете никаких глупых транзакций по обслуживанию таблиц. Никакой код не превосходит Python или PHP.

  • После того, как вы познакомитесь с механизмом шаблонов и CSS, вы можете настроить интерфейс администратора так, чтобы он выглядел как угодно. Это материал HTML / CSS, а не Python или PHP.

Нижняя граница. Большая часть набора навыков - это Python. ORM - синтаксически - Python, но требует некоторой осторожности, чтобы делать вещи просто и чисто. Шаблон - это собственный язык, но значительно проще, чем PHP. Остальное - это SQL, Javascript, HTML, CSS, Apache и тому подобное.

Редактировать

Зрелость Джанго

• См. Количество активных проектов в http://www.djangoproject.com/community/.

• Присоединяйтесь к http://groups.google.com/group/django-users, чтобы получать ежедневный поток писем от пользователей.

Блог Django восходит к '05, а это означает, что у них были годы солидного опыта, прежде чем, наконец, выпустили 1.0 в сентябре '08. Очевидно, разработка началась в 2003 году.

Просто пропустите PHP и используйте Python (с Django, как уже было замечено, когда я печатал). Django уже разделяет слои, как вы упомянули.

Сам я никогда не использовал PgSQL, но думаю, что предпочтение от него над MySQL - дело вкуса. Раньше он поддерживал больше корпоративных функций, чем MySQL, но я не уверен, что это все еще верно для MySQL 5.0 и 5.1. В любом случае транзакции поддерживаются в MySQL (однако вы должны использовать механизм таблиц InnoDB).

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

Если у вас нет предпочтений, вы можете использовать MySQL просто потому, что он более популярен для работы в Интернете. Это приводит к появлению большего количества примеров, облегчению поиска помощи и т. д. На самом деле я предпочитаю философию PgSQL, но это не достаточно веская причина, чтобы дуть против ветра.

Я собираюсь предположить, что под «бизнес-приложением» вы подразумеваете веб-приложение, размещенное в среде интрасети, а не какое-то приложение SaaS в Интернете.

Пока вы разрабатываете архитектуру своего приложения, вам необходимо учитывать существующую инфраструктуру и людей, обслуживающих инфраструктуру, вашего работодателя / клиента. Кроме того, если компания достаточно велика, чтобы иметь такие вещи, как «списки утвержденного программного и аппаратного обеспечения», вам следует об этом знать. Имейте в виду, что некоторые элементы списка могут быть просто запаздывающими. Не позволяйте прошлым ошибкам определять архитектуру вашего приложения, но в тех случаях, когда они разумны, я бы выбрал свои сражения и придерживался вашего корпоративного стандарта. Это может быть настоящей болью, когда вы выбираете стек разработки, который действительно лучше всего работает в Unix / Linux, а затем кто-то пытается принудительно подключиться к серверу Windows, администрируемому кем-то, кто никогда не касался ничего, кроме приложений ASP.NET.

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

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

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

Просто чтобы выбросить это там ... есть PHP-фреймворки, использующие MVC.

Codeigniter делает простые, но мощные вещи. Вы определенно можете отделить слой шаблона от слоя логики.