чистый php или framework
Чистый PHP vs PHP фреймворков
В этой статье не рассматриваются технические термины и концепции, чтобы обеспечить ее содержание простым. Если вы программист, позвольте мне рассказать вам, почему вы должны предпочесть использовать фреймворки вместо чистого PHP для своих проектов. Если вы являетесь предпринимателем, позвольте мне рассказать, почему так важно настаивать на том, чтобы ваш разработчик программного обеспечения разрабатывал веб-приложения и веб-сайты с помощью PHP фреймворков.
Сравнение чистого PHP и PHP фреймворка может быть похоже на математику.
Чтобы решить сложную задачу в математике, вы можете либо взять лист бумаги, либо использовать научный калькулятор для ее решения.
Нахождение решения математической задачи на бумаге похоже на кодирование на чистом PHP, использование же научного калькулятора похоже на кодирование с использованием фреймворков.
Так что я имею в виду?
Каждый студент может решить проблему с точностью 100%, как только они узнают, как использовать калькулятор. Предопределенные формулы в калькуляторе будут давать точные результаты быстрее.
Проблема с чистым PHP
Чистый PHP становится сложным, когда люди начинают писать свою собственную логику. Кто-то сможет решить поставленную задачу в несколько строк кода, а кто-то не сможет и в несколько сотен. А в результате оба они не могут читать код друг друга. Итак, проблема, которая зарождается здесь, это несогласованность.
Почему выбирают фреймворки?
Фреймворк обеспечивает надежность, согласованность и большую экономию времени. Он имеет богатый набор функций, поэтому вам не нужно повторно изобретать колесо. У вас будет практически все функциональные возможности для разработки веб-приложения PHP. Поскольку он был разработан в стиле ООП, вы можете расширить существующую функциональность, чтобы иметь полный контроль над приложением. Фреймворк не позволит вам писать плохой код, если, конечно, вы намеренно это не делаете. Когда вы работаете в команде, интеграция всего вашего модуля становится очень легкой, а также фреймворк помогает в понимании кода друг друга.
Тогда неужели чистый PHP так плох?
Абсолютно нет. Чистый PHP помогает понять логику фреймворка. Ваше логическое мышление может быть улучшено с помощью чистого PHP. Однако нативный PHP становится плохим только тогда, когда он попадает на стол плохого программиста. Не погружайтесь в фреймворк без опыта кодирования на чистом PHP. Также, убедитесь, что вы прочитали полную документацию по фреймворку, прежде чем начинать кодирование в нем, так как в настоящее время стало “модно”, использовать нативный PHP внутри фреймворка, но это абсолютно неверный путь использования такого полезного инструмента.
А вообще, проще всего разобраться с тем, что такое фреймворки можно с помощью моего курса Фреймворк Yii 2.0 с нуля. Пример создания сайта.
Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!
Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.
Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления
Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.
Порекомендуйте эту статью друзьям:
Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):
Ребят нужны те кто с опытом, никак не могу определится писать на чистом или фреймворке PHP?
опять круд опять роуты все одно и тоже
Прекрасно, вы уже поняли зачем нужны фреймворки, т.к. без толку переходить на них пока нет понимания
Как вы считаете, нужно ли годик кодить для себя на чистом языке?
Желательно но в вопросе нет информации сколько вы уже кодите
Что будет, чем грозит если я буду сразу на фреймворке работать?
Непонимание того зачем во фреймворке сделали именно так а не иначе, почему всё так сложно и что если этого не делать
роутеры и прочее, уже опять же привык, к мвц
роутинг можно взять готовый, и MVC реализовать самому быстро
Так вы за опыт кодите, у меня были проекты не на фреймворках, ни об одном не жалею
В общем ваше мнение как поступать?
Дмитрий если бьрать по 8 ч в день (что интересно я не особо много создавал роуты но сразу оценил как во фреймворке сделано удобно) )))
2 месяца или 3 по 8 ч в день может 4.
Непонимание того зачем во фреймворке сделали именно так а не иначе, почему всё так сложно и что если этого не делать
в том то и дело, что если опять делать мвц то будет тоже самое почему нужно мвц и что будет если не делать так, а я если честно сразу делал на мвц и уже тогда скринкасты и мозг помогли понять что так гораздо удобнее без единой строчке кода без мвц))
Современный PHP без фреймворков
У меня есть для вас непростое задание. Когда в следующий раз начнёте новый проект, постарайтесь обойтись без PHP-фреймворка. Я не собираюсь перечислять недостатки фреймворков, и это не проявление синдрома неприятия чужой разработки: в этом руководстве мы будем использовать пакеты, написанные разработчиками нескольких фреймворков. Я всецело уважаю инновации в этой сфере.
Но эта статья не о них. Она о вас. О возможности стать лучше как разработчик.
Возможно, главным плюсом отказа от фреймворка станет знание, как всё работает под капотом. Вы будете видеть, что происходит, не полагаясь на фреймворк, который заботится о вас настолько, что вы не можете что-то отладить или до конца понять.
Возможно, ваша следующая работа не позволит вам насладиться запуском нового проекта без фреймворка. Многие важные, критические для бизнеса PHP-задачи подразумевают использование уже существующих приложений. И неважно, будет это приложение, построенное на современном фреймворке вроде Laravel или Symfony, на одной из старых платформ вроде CodeIgniter или FuelPHP — либо это удручающе широко распространённое легаси PHP-приложение с «include-oriented архитектурой»: если сейчас вы будете разрабатывать без фреймворка, то окажетесь лучше подготовлены к любому будущему PHP-проекту.
Раньше создавать без фреймворков пытались потому, что некоторые системы вынуждены интерпретировать и маршрутизировать HTTP-запросы, слать HTTP-ответы и управлять зависимостями. Нехватка стандартов неизбежно приводила к тому, что как минимум эти компоненты фреймворков были тесно взаимосвязаны. Так что если вы начинали разрабатывать проект без фреймворка, то в конце концов приходили к созданию своего собственного фреймворка.
Но сегодня благодаря стараниям PHP-FIG в сфере автозагрузки и взаимной совместимости вы можете разрабатывать без фреймворка, не создавая его попутно. Существует множество замечательных, взаимно совместимых пакетов, написанных многочисленными разработчиками. И собрать их в единую систему гораздо проще, чем вы думаете!
Как работает PHP?
Прежде всего важно понять, как PHP-приложения взаимодействуют с внешним миром.
PHP исполняет серверные приложения в цикле запрос/ответ. Всё взаимодействие с приложением — из браузера, командной строки или REST API — приходит в него в качестве запросов. При получении запроса приложение загружается, обрабатывает запрос и генерирует ответ, который передаётся обратно клиенту, а приложение закрывается. И так происходит при каждом обращении.
Контроллер запросов
Вооружившись этим знанием, начнём с фронт-контроллера. Он представляет собой PHP-файл, обрабатывающий все запросы к вашему приложению. То есть это первый PHP-файл, в который попадает запрос, и (по сути) последний PHP-файл, через который проходит ответ приложения.
Давайте воспользуемся классическим примером с Hello, world!, обслуживаемым встроенным в PHP веб-сервером, чтобы проверить, всё ли настроено корректно. Если вы этого ещё не сделали, то удостоверьтесь, что в среде установлен PHP 7.1 или выше.
Обратите внимание, здесь мы объявляем строгую типизацию — это нужно делать в начале каждого PHP-файла вашего приложения, — потому что подсказки типов (type hinting) важны для отладки и ясного понимания теми, кто будет заниматься кодом после вас.
Далее с помощью инструмента командной строки (вроде Terminal на MacOS) перейдём в директорию проекта и запустим встроенный в PHP веб-сервер.
Теперь откроем в браузере адрес http://localhost:8080/. Отображается Hello, world! без ошибок?
Отлично. Переходим к следующему шагу!
Автозагрузка и сторонние пакеты
Когда вы впервые начали работать с PHP, то, вероятно, использовали выражения include или require для получения функциональности или конфигураций из других PHP-файлов. В целом этого лучше избегать, потому что другим людям потом будет гораздо труднее разобраться в коде и понять, где находятся зависимости. Это превращает отладку в кошмар.
Выход — автозагрузка. Это означает, что, когда вашему приложению нужно использовать какой-то класс, PHP знает, где его найти, и автоматически загружает в момент вызова. Эта возможность существует со времён PHP 5, но стала активно применяться только с появлением PSR-0 (стандарта автозагрузки, сегодня заменён PSR-4).
Можно было бы пройти через тягомотину написания собственного автозагрузчика, но раз мы выбрали Composer для управления сторонними зависимостями, а в нём уже есть очень удобный автозагрузчик, то его мы и будем использовать.
Проверьте, что у вас установлен Composer. Затем настройте его для своего проекта.
Теперь установите для этого проекта Composer, которые подтянет все зависимости (если они уже есть) и настроит для нас автозагрузчик.
Обновите public/index.php для запуска автозагрузчика. В идеале это одно из нескольких выражений include, которые вы используете в приложении.
Если перезагрузить приложение в браузере, вы не увидите никакой разницы. Однако автозагрузчик работает, просто он не делает ничего тяжёлого. Давайте перенесём пример с Hello, world! в автоматически загружаемый класс, чтобы проверить, как всё работает.
В корне проекта создадим папку src и вставим в неё файл HelloWorld.php с таким кодом:
Перезагрузите приложение в браузере и увидите новое сообщение!
Что такое внедрение зависимостей?
Внедрение зависимостей — это методика, при которой каждая зависимость предоставляется объекту, которому она требуется, вместо того чтобы объект обращался наружу за получением какой-то информации или функциональности.
Допустим, методу класса нужно считать из базы данных. Для этого надо к ней подключиться. Обычно новое подключение создаётся с учётными данными, полученными из глобального пространства.
Но это не лучшее решение. На чуждый метод возлагается ответственность за создание объекта нового подключения к БД, получения учётных данных и обработки любых проблем в случае сбоя подключения. В результате в приложении дублируется масса кода. А если вы попытаетесь прогнать этот класс через модульное тестирование, то не сможете. Класс тесно взаимосвязан со средой приложения и базой данных.
Давайте с самого начала не будем усложнять работу с тем, что требуется классу. Просто в первую очередь потребуем, чтобы объект PDO был внедрён в класс.
Получилось гораздо чище и проще для понимания, меньше вероятность ошибок. Благодаря подсказке типов и внедрению зависимостей метод объявляет именно то, что ему нужно для выполнения задачи, и получает необходимое без вызова из себя внешней зависимости. А когда речь пойдёт о модульном тестировании, мы окажемся готовы к моделированию подключения к БД и спокойно пройдём тест.
Контейнер внедрения зависимости — это инструмент, в который вы обёртываете всё ваше приложение ради создания и внедрения этих самых зависимостей. Контейнер не является необходимым, но значительно облегчает жизнь по мере роста и усложнения вашего приложения.
Мы воспользуемся самым популярным DI-контейнером для PHP с изобретательным названием PHP-DI. (Надо отметить, что в его документации внедрение зависимостей описано иначе, и кому-то так будет понятнее.)
Контейнер внедрения зависимостей
Поскольку мы настроили Composer, установка PHP-DI пройдёт практически безболезненно. Для этого снова обратимся к командной строке:
Обновите public/index.php для конфигурирования и сборки контейнера.
Ничего особенного пока не произошло. Это лишь простой пример, где всё необходимое помещено в один файл для удобства наблюдения.
Заметка на полях: автоматическое внедрение зависимостей может быть полезной фичей в начале создания приложения, но в дальнейшем оно усложняет сопровождение, поскольку зависимости остаются относительно скрытыми. К тому же возможно, что через несколько лет другой разработчик подключит какую-нибудь библиотеку, и в результате несколько библиотек будут реализовывать один интерфейс. Это сломает автоматическое внедрение зависимостей и приведёт к непредсказуемому потоку багов. Разработчик, внёсший изменение, может их вообще не заметить.
Давайте ещё больше всё упростим, импортировав пространства имён там, где это возможно.
Пока что выглядит всё так, словно мы устроили суматоху ради выполнения того, что уже делали раньше.
Не беспокойтесь, контейнер нам пригодится, когда добавим несколько других инструментов, помогающих передавать запросы напрямую через приложение. Эти инструменты будут использовать контейнер для загрузки правильных классов по мере необходимости.
Middleware
Если представить приложение в виде луковицы, в которой запросы идут снаружи к центру, а ответы в обратном направлении, то middleware — это каждый слой луковицы, который получает запросы, вероятно, что-то делает с ответами и передаёт их в нижний слой либо генерирует ответ и отправляет в верхний слой. Такое случается, если промежуточный слой проверяет запросы на соответствие каким-то условиям вроде запроса несуществующего пути.
Если запрос проходит до конца, приложение обработает его и превратит в ответ. После этого каждый промежуточный слой в обратном порядке будет получать ответ, возможно, модифицировать его и передавать следующему слою.
Варианты использования промежуточных слоев:
Промежуточный слой — это единственный способ реализации инструментов для обработки всех этих ситуаций? Вовсе нет. Но реализации middleware позволяют сделать цикл запрос/ответ гораздо понятнее, что сильно упростит отладку и ускорит разработку.
Мы воспользуемся промежуточным слоем для последнего сценария: маршрутизации.
Маршрутизация
Маршрутизатор применяет информацию из запроса, чтобы понять, какой класс должен его обработать (например, URI /products/purple-dress/medium должен быть обработан с помощью класса ProductDetails::class с передаваемыми в качестве аргументов purple-dress и medium ).
Наше приложение будет использовать популярный маршрутизатор FastRoute через реализацию промежуточного слоя, совместимого с PSR-15.
Диспетчер middleware
Чтобы наше приложение стало работать с каким-либо промежуточным слоем, нам понадобится диспетчер.
PSR-15 — это стандарт, определяющий интерфейсы для middleware и диспетчеров (в спецификации они называются «обработчики запросов»), обеспечивающий взаимосовместимость широкого спектра решений. Нам лишь нужно выбрать диспетчер, совместимый с PSR-15, и он будет работать с любым совместимым middleware.
В качестве диспетчера установим Relay.
А поскольку спецификация PSR-15 подразумевает, чтобы реализация промежуточного слоя передавала HTTP-сообщения, совместимые с PSR-7, мы воспользуемся Zend Diactoros.
Подготовим Relay к приёму промежуточных слоев.
Теперь добавим FastRoute и обработчика запросов ( FastRoute определяет, валиден ли запрос и может ли он быть обработан нашим приложением, а обработчик запросов передаёт запрос тому обработчику, что сконфигурирован для этого маршрута).
Теперь откройте http://localhost:8080/hello и наслаждайтесь своим успехом!
Клей, который всё скрепляет вместе
Проницательный читатель заметит, что DI-контейнер, несмотря на все трудности его конфигурирования и сборки, на самом деле ничего не делает. Диспетчер и промежуточное ПО могут работать и без контейнера.
Так зачем он нужен?
А что, если — как это почти всегда бывает в реальных приложениях — у класса HelloWorld есть зависимость?
Давайте её добавим и посмотрим, что произойдёт.
Перезагрузим браузер, и.
Это происходит потому, что для функционирования HelloWorld требуется при его создании внедрить строковое значение, а у нас это повисло в воздухе. И здесь на помощь приходит контейнер.
Давайте определим зависимость в контейнере и передадим его в RequestHandler для разрешения.
Вуаля! При перезагрузке браузера вы должны увидеть Hello, bar world!.
Правильная отправка ответов
Просто ничего с ним не делает.
Нам нужен ещё один инструмент: эмиттер. Он находится между приложением и веб-сервером (Apache, nginx и т. д.) и отправляет ваш ответ клиенту, сгенерировавшему запрос. Эмиттер просто берёт объект Response и преобразует в инструкции, доступные для понимания серверным API.
Для простоты примера мы используем здесь очень простой эмиттер. Хотя он может быть гораздо сложнее, но в случае больших загрузок реальное приложение должно быть сконфигурировано для автоматического использования потокового эмиттера. Это хорошо описано в блоге Zend.
Обновим public/index.php для получения Response от диспетчера и передачи в эмиттер.
Перезагрузим страницу — мы снова в деле! Пришло время для более надёжной обработки ответов.
В строке 15 заканчивается цикл запрос/ответ и вступает в работу веб-сервер.
Завершение
С помощью 44 строк кода и нескольких широко используемых, тщательно протестированных, надёжных, взаимодействующих друг с другом компонентов мы реализовали программу bootstrap современного PHP-приложения. Он совместим со стандартами PSR-4, PSR-7, PSR-11 и PSR-15, поэтому вам доступен широкий спектр реализаций HTTP-сообщений, DI-контейнеров, middleware и диспетчеров.
Мы углубились в некоторые технологии и аргументацию, но я надеюсь, вам очевидна простота программы начальной загрузки нового приложения без сопутствующего хлама фреймворка. Также надеюсь, что вы теперь лучше готовы к применению этих технологий в существующих приложениях.
Использованное в статье приложение лежит в репозитории, можете свободно форкать и скачивать.
Какой подход программирования на PHP выбрать в 2020 году?
Я тут вопрос задавал относительно своего старого кода. Спасибо огромное за критику и конструктивные советы.
Теперь следующий вопрос. Мне бы ознакомиться с тем, как сейчас программируют, лучше на каком нибудь примере. Возможно простейшее веб приложение на основе MVC или тп. Может что то на GitHub посмотреть. Только не сложное, ознакомиться с принципами.
Наверное, можно начать ковырять какой нибудь фреймворк типа YII, но думаю будет сложновато..
Простейшее веб приложение уже не отразит суть всех тенденций. Или его сложно будет назвать простейшим) Правильно советуют phptherightway, из этого обязательно стоит отметить:
— стандарты psr
— сборка проекта через composer, знание самых популярных пакетов и где их искать
— знакомство с IoC (Di) контейнером
— знание хотя бы одной популярной ORM
— уверенная работа в IDE (погуглить основные лайфхаки пхпшторма)
Обычно пара официальных вводных курсов по фреймворкам знакомит со всеми этими вещами. Yii2 давно отстает от тенденций
Фреймворк (framework, «каркас», «конструкция») — это динамически пополняемая библиотека языка программирования, в которой собраны его базовые модули. Фреймворки создаются для упрощения процессов разработки приложений, сайтов, сервисов. Чтобы не писать модуль в приложении с нуля, гораздо проще обратиться к готовым шаблонам фреймворков, которые и формируют рабочую среду разработчика.
Подитожим. Ваши знания находятся примерно на уровне 2015-2016 годов, как мне кажется. И тут Вам придется решать самому: либо пойти по плавному развитию, пробуя сначала Yii2, со старыми подходами, но ближе к вашим знаниям, а потом перейти на Laravel или Symfony, либо сразу пойти в 2020 год и использовать Laravel или Symfony, которые соответствуют современным подходам, но дальше от Ваших знаний. Можете попробовать установить все и решить для себя на каком фреймворке будете проходить изучение.
Знакомство с фреймворками. Часть 1. HTML/CSS, PHP и Python
Этой статьей я хочу начать цикл материалов, посвященных фреймворкам: что такое фреймворки, зачем они нужны, и какие бывают.
Что такое фреймворк
Если обратиться к истории самого слова «фреймворк», то этот неологизм появился в языке относительно недавно, примерно в начале XXI века. С английского слово “framework” можно перевести как «конструкция», «структура», «каркас», «корпус» или «остов». Понимание перевода слова ведет к понимаю сути фреймворка: это специальная программная среда выполнения, программный каркас, который облегчает разработку программ и объединение компонентов, так как уже содержит в себе некую основу, не меняющуюся от конфигурации к конфигурации часть, которую следует лишь наполнить сменными моделями или точками расширения.
В отличие от динамической библиотеки (DLL), которая предоставляет собой лишь набор ограниченных функций, фреймворк является каркасом, согласно которому будет строиться архитектура приложения, то есть он определяет взаимосвязь между компонентами. Более того, фреймворк может содержать много разных по тематике библиотек.
При этом фреймворки можно поделить на следующие виды:
В данном цикле в поле нашего зрения окажутся фреймворки, которые относятся к первому типу и помогают разрабатывать веб-проекты.
Сравнение чистого кода, фреймворка и CMS
Перед созданием сайта программисту нужно решить, по какому из трех возможных путей разработки сайта он хочет пойти.
Первый вариант – это написание исходного кода с нуля. Такой путь удобен, так как дает свободу действий и практически неограниченный функционал, который можно реализовать. Среди минусов необходимо выделить трудоемкость и растянутость во времени, а также необходимость тщательно тестировать готовый продукт на предмет ошибок и недоработок.
Второй вариант – это использование фреймворков. Безусловно, этот вариант имеет ряд ограничений, если сравнивать его с предыдущим путем: у вас уже будет готовая основа, которую необходимо будет заполнить нужными компонентами. Естественно, даже такой вариант не подойдет тем, кто мало знаком с программированием, и именно поэтому на свет появился третий способ создания сайта.
Третий вариант – установка готовой CMS. Этот путь популярен у людей, далеких от веб-разработки, так как он позволяет легко и быстро создать свой собственный сайт, при этом все необходимые действия можно выполнять из административной панели. Но в то же время этот подход является самым несвободным по сравнению с предыдущими двумя и обладает массой ограничений.
Таким образом, фреймворк – это некий компромисс между написанием собственного кода и использованием готовой системы управления контентом. Фреймворк обеспечивает проект уже готовым каркасом, при этом не лишает его функциональной гибкости.
Необходимые для веб-разработки фреймворки чаще всего делят по принципу языка, к которому они относятся. В данной и следующей статьях я последовательно рассмотрю, какие фреймворки существуют, и в чем заключаются их особенности.
HTML/CSS-фреймворки
HTML/CSS-фреймворкиBootstrap (или Twitter Bootstrap) – один из самых известных и современных фреймворков, впервые анонсированный в 2011 году. Одно из главных свойств этого фреймворка – адаптивность. Используя Bootstrap, вы можете создать сайт с отзывчивым дизайном: ваш проект будет самостоятельно подстраиваться под размер экрана пользователя. Другие плюсы этого фреймворка: простота в использовании, наличие множества шаблонов и стилей, что значительно экономит время при разработке, согласующийся постраничный дизайн, открытое программное обеспечение. Bootstrap нельзя назвать только HTML/CSS-фреймворком, так как он включает в себя также готовые стили и плагины под jQuery (библиотека на JS).
Foundation – один из ведущих front-end-фреймворков на данный момент. В последних версиях авторы сделали упор на функционал для мобильных устройств. Семантический подход позволяет писать более чистый код на HTML и использовать SCSS. Этот фреймворк хорошо подходит для быстрого прототипирования.
Semantic UI – этот фреймворк, как и Bootstrap, поможет вам создать переносимые интерфейсы. Это достаточно молодой фреймворк, который постоянно развивается; он имеет множество различных кнопок, иконок, изображений, надписей и других элементов.
Uikit – фреймворк, обладающий легкой и модульной структурой. Выделяется на фоне остальных фреймворков двумя особенностями: во-первых, markdown (предварительный просмотр в реальном времени), во-вторых, синтаксическая подсветка для HTML.
Pure by Yahoo! – фреймворк, который содержит небольшие адаптивные CSS-модули, пригодные для использования в любом проекте. Как можно понять из названия, к этому фреймворку стоит обращаться тогда, когда вам нужно использовать некоторые возможности фреймворка, но в то же время вы не хотите использовать слишком тяжелый программный каркас.
PHP-фреймворки
Yii – фреймворк, название которого расшифровывается как “Yes, it is!”, существует уже более 8 лет и постоянно обновляется. У него широкие возможности: одна из самых высоких производительностей (по сравнению с другими фреймворками), кэширование, обработка ошибок, миграция баз данных, возможность использовать и объединяться с jQuery и многое другое. В отличие от других PHP-фреймворков, Yii можно изучить достаточно быстро, работа с ним стабильна и безопасна. Именно по этим причинам данный фреймворк часто советуют тем, кто только начинает свой путь в PHP-программировании.
Laravel – этот фреймворк часто лидирует в разнообразных опросах, касающихся PHP-фреймворков. Например, в 2013 году Laravel был назван самым многообещающим проектом 2014 года, а в 2015 году занял первые места в категориях «Фреймворк корпоративного уровня» и «Фреймворк для личных проектов». Laravel прост в освоении и отлично подходит для небольших и средних проектов, когда необходимо быстро и удобно написать код.
Symfony – этот фреймворк часто рекомендуют использовать для создания больших порталов, так как его можно назвать одним из самых стабильных PHP-фреймворков. Это гибкий и масштабируемый фреймворк со значительным функционалом. Symfony содержит полезные многоразовые компоненты, касающиеся безопасности, шаблонов, перевода, настройки форм и многого другого.
CodeIgniter – один из старейших фреймворков, первый публичный релиз которого состоялся в 2006 году. Этот фреймворк имеет массу преимуществ: быстрая установка, хорошая документация, малый вес; с ним вы можете легко реализовать задуманный проект. Именно поэтому некоторые начинают освоение фреймворков именно с CodeIgniter. Немаловажным фактом также являются регулярные релизы новых версий, в которых исправлены баги и добавлены новые возможности.
Phalcon PHP – написанный на языках программирования C, С++ и PHP фреймворк имеет открытый исходный код, а также предлагает разные версии для самых популярных операционных систем: Windows, Linux и Mac. Если взять во внимание тесты, то данный фреймворк является одним из самых производительных. Также Phalcon PHP можно использовать на собственных серверах.
Python-фреймворки
Django – это один из самых известных фреймворков в целом и, безусловно, самый популярный фреймворк на языке Python. Удивительно, но для того, чтобы начать использовать Django, вам даже не нужны глубокое знание языка Python. Отличительной особенностью Django является его принцип DRY, который расшифровывается как “Don’t repeat yourself”. Мысль, выраженная в этой фразе, ведет к тому, что разработчикам не следует повторять те строки кода, которые они уже использовали, и благодаря этому исходный код выглядит более лаконично и понятно. К преимуществам фреймворка можно также отнести стандартную структуру (благодаря которой даже сторонний программист сможет разобраться в коде) и наследование шаблонов. Многие знакомы с Django в качестве системы администрирования, однако эта CMS подойдет только опытным пользователям, знакомым с программированием.
Flask – данный фреймворк также называют расширяемым микрофрейморком. Это связано с тем, что изначально в Flask заложен лишь самый необходимый функционал, который затем можно расширять до уровня, который необходим проекту. Обилие расширений решит практически любую задачу, которую вы перед собой поставите. Поэтому свое ознакомление с Python-фреймворками многие советуют начать именно с Flask.
TurboGears – известный Python-фреймворк с более чем 10-летней историей. Он предназначен для разработки веб-проектов и состоит из различных WSGI-компонентов, в том числе Pylons и CherryPy. Благодаря этому можно говорить о TurboGears как о мощном фреймворке с богатым функционалом. Он поддерживает множество баз данных и форматов обмена данными, также поддерживает различные JavaScript-библиотеки и горизонтальное масштабирование данных.
Tornado – этот фреймворк выделяется на фоне остальных своей главной особенностью, а именно способностью решить проблему 10 тысяч соединений. Неблокирующая природа сервера, использующего Torando, позволяет ему легко выдерживать тысячи недлительных подключений, которые произведены в одно время.
Web2spy – этот фреймворк, как и некоторые другие, основывается на концепции RAD (rapid application development). Иными словами, при его разработке особое внимание было уделено оптимизации процесса создания проекта, чтобы программист мог как можно быстрее создать хороший продукт. Фреймворк имеет открытый исходный код и помогает создавать динамические сайты при помощи языка Python. Это полнофункциональный фреймворк, который содержит компоненты для всех основных функций.
Во второй части будут рассмотрены фреймворки следующих языков программирования: Ruby, Java, JavaScript.