Я ищу некоторые быстрые мысли о бизнес-приложении, которое я собираюсь построить. Я бы хотел разделить три уровня представления , логику домена и данные с помощью PHP , Python и PostgreSQL , соответственно. Я хотел бы услышать, возможно, от других людей, которые раньше пошли по этому пути, если есть проблемы с этим подходом, если я нацелен на неправильные инструменты и т. Д.
Я смотрю на PHP, потому что он широко используется, довольно зрелый, и я могу найти достаточно людей с навыками в дизайне интерфейса PHP.
Я смотрю на Python из-за преимуществ читаемого кода, потому что, как я слышал, можно найти больше программистов на Python, которые также обладают предметными навыками (в данном случае, финансами), и это язык с открытым исходным кодом. Кроме того, с этим проще скомпилировать.
Я смотрю PostgreSQL для функций уровня транзакции. MySQL также является вариантом, но мне не нужно обсуждать этот аспект.
Это не веб-приложение, хотя я бы хотел использовать браузер для пользовательского интерфейса. Это скорее корпоративное приложение, а для малого бизнеса с умеренным числом пользователей (возможно, 5-10) и скромное количество ежедневных транзакций.
Важно то, что мы можем модернизировать логику или интерфейс базы данных или домена отдельно от других слоев в будущем.
Я НЕ Ищем дискуссию о покупке или строительстве , поскольку это другое обсуждение.
Спасибо за понимание
Посмотрите на Django .
Код Python. Язык шаблонов, допускающий некоторые из тех же функций, что и PHP, – немного другой синтаксис.
Модель отделена от функций вида («бизнес-правил») и отделена от презентации. Это выполняется в Django.
Один из распространенных вопросов – «почему я не могу это сделать – какая-то сумасшедшая PHP-подобная вещь – в шаблоне Django?» Ответ заключается в том, что презентация не обрабатывается. Выполняйте обработку в функциях представления Django. Отобразить результаты в формате HTML в шаблоне.
Кроме того, Django имеет уровень ORM, чтобы развестись с небольшими соображениями SQL. MySQL или PostgreSQL более или менее эквивалентны из Django.
редактировать
«Зрелость» означает много чего. Вы специально упомянули квалифицированных людей как знак зрелости.
Django – чистый Python. Если вы можете найти людей Python, они могут изучить Django через несколько дней. Они просто должны делать уроки.
Сайт, на котором работает Django, обычно Apache + некоторый клей + 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, BTW.
Вы не пишете ни одной транзакции по обслуживанию немой таблицы. Никакой код вообще не превосходит Python или PHP.
После того, как вы намочите ноги с помощью механизма шаблонов и CSS, вы можете настроить интерфейс администратора так, чтобы он выглядел как угодно. Это материал HTML / CSS, не Python или PHP.
Нижняя линия. Большая часть набора навыков – Python. ORM – синтаксически – Python, но требует некоторой осторожности в том, чтобы делать вещи просто и чисто. Шаблон – это собственный язык, но значительно проще, чем PHP. Остальное – SQL, Javascript, HTML, CSS, Apache и что-нет.
редактировать
Срок погашения Django
См. http://www.djangoproject.com/community/ для количества активных проектов.
Присоединитесь к http://groups.google.com/group/django-users для ежедневного потока писем от пользователей.
Блог Django простирается до '05, то есть у них много лет опыта, прежде чем, наконец, выпустив 1.0 в сентябре 2008 года. Развитие, по-видимому, началось в '03.
Я предполагаю, что под «бизнес-приложением» вы подразумеваете веб-приложение, размещенное в среде интрасети, а не какое-то приложение SaaS в Интернете.
Пока вы разрабатываете приложение, вам необходимо учитывать существующую инфраструктуру и инфраструктуру для поддержки вашего работодателя / клиента. Кроме того, если компания достаточно велика, чтобы иметь такие вещи, как «одобренные списки программного обеспечения / аппаратного обеспечения», вы должны знать об этом. Имейте в виду, что некоторые элементы списка могут быть просто отсталыми. Не допускайте, чтобы прошлые ошибки диктовали архитектуру вашего приложения, но в тех случаях, когда они разумно разумны, я бы выбрал свои битвы и придерживался вашего корпоративного стандарта. Это может быть настоящей болью, когда вы выбираете стек разработки, который действительно лучше всего работает на Unix / Linux, а затем кто-то пытается навязать на сервер Windows, которого поддерживает тот, кто никогда не касался ничего, кроме приложений ASP.NET.
Если не существует определенного PHP-модуля, который вы собираетесь использовать, который не имеет эквивалента Python, я бы бросил PHP и использовал Django. Если у вас есть веская причина использовать PHP, я бы бросил Python. Мне трудно представить себе сценарий, в котором вы хотели бы использовать оба одновременно.
Что касается PG и MySQL, то работает. Посмотрите, что вы уже развернули, и если у вас есть куча одного и другого, выберите это. Если у них есть существующая инфраструктура Oracle, вы должны ее использовать. Если они являются магазином SQL Server … пересматривайте свой стек и не забывайте выбирать свои битвы.
Я могу только повторить то, что уже говорили другие народы: если вы выберете Python для домена, вы ничего не выиграете (скорее наоборот), используя PHP для уровня представления. Другие уже сообщили Django, и это может быть довольно хорошим выбором, но нет недостатка в хороших веб-фреймах Python.
Я лично согласен со вторым и третьим пунктами в вашем сообщении. Говоря о PHP, на мой взгляд, вы также можете использовать Python для презентации, существует множество решений (Zope, Plone …) на основе Python.
Просто пропустите PHP и используйте Python (с Django, как уже заметил, когда я набирал). Django уже разделяет слои, как вы упомянули.
Я никогда не использовал PgSQL самостоятельно, но я думаю, что это в основном вопрос вкуса, предпочитаете ли вы его в отношении MySQL. Он использовался для поддержки большего количества корпоративных функций, чем MySQL, но я не уверен, что это все еще верно для MySQL 5.0 и 5.1. Однако транзакции поддерживаются в MySQL, но вам все равно нужно использовать движок таблицы InnoDB.
Просто для решения проблем MySQL и PgSQL – это не имеет значения. Они оба более чем способны выполнить эту задачу, и любые разумные рамки должны изолировать вас от различий относительно хорошо. Я думаю, что дело доходит до того, что вы используете уже, что люди имеют больше всего опыта, и если есть какая-то особенность в том или ином, вы считаете, что вам это выгодно.
Если у вас нет предпочтений, вы можете пойти с MySQL исключительно потому, что он более популярен для работы в Интернете. Это приводит к большему количеству примеров, проще найти помощь и т. Д. На самом деле я предпочитаю философию PgSQL, но это не очень хорошая причина для удара по ветру.
Просто, чтобы выбросить его там … существуют фреймворки PHP, использующие MVC.
Codeigniter делает простые и, тем не менее, мощные вещи. Вы можете определенно отделить слой шаблона от логического уровня.