Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 249
приделывать костыли к велосипеду, чтобы он ехал :)
Как хорошо вы описали работу на самописах. В целом если тесты пишите — то как хотите делайте и на чем хотите. Если же нет — то… для таких людей есть особенное место в аду.
В итоге вы получаете свой велосипед со своими костылями и граблями, которые также придется обходить.
Вы уверены, что обладаете достаточной квалификацией, чтобы отличить костыль от качественного решения? Что не разложили грабли по незнанию либо недосмотру? Что получается лексус, а не заниженная приора?
В итоге я получаю Лексус ручной сборки. :)
А ваш клиент платит соответственно, а мог бы получить какой-нибудь опель и ехать а не дом закладывать второй раз.
Граблей нету, так как я их не расставлял.
вы просто пока на них не наступили, но они есть, там где-то под листвой.
В своих проектах костылей не держу.
А как вы тогда называете "временные решения"?
К сожалению на фреймворках костыли приходится использовать, так как настаивает заказчик.
Я прям так и вижу "слушай чувак, мне надо фичу запилить, сделай пожалуйста так что бы кастыль вот в этом месте".
какой PHP фреймворк вы выберете для создания среднего или крупного проекта (корпоративный портал, магазин и т.п.) в 2016 году?
Абсолютно бесполезная статистика. Намного интереснее было бы посмотреть корреляцию между: предпочитаемым фреймворком, опытом коммерческой разработки, опытом работы в команде, средним размером проекта. Только для размера проекта надо метрики еще выдумывать.
Я же маленькие личные проекты я скорее буду делать на Ayres шутки ради, а коммерческие — symfony.
p.s. ошибся веткой.
Вопрос "какой фреймворк лучше" почти каждый день спрашивают на тостере, это неизменно приводит к холивару. А в данном голосовании вопрос задан: на каком фреймворке вы будете писать приложение, т.е. подразумевается, что стадия сравнения, споров и выбора уже прошла, и тимлид или команда или бизнес решили: по факту будем писать на…
И речь в голосовании идет именно о средних и крупных проектах, маленькие личные — ни в счет.
Хочется узнать фактический мейнстрим на 2016 год, то есть что будет на самом деле, а ни этот хороший, а тот плохой.
И речь в голосовании идет именно о средних и крупных проектах, маленькие личные — ни в счет.
Хочется узнать фактический мейнстрим на 2016 год, то есть что будет на самом деле, а ни этот хороший, а тот плохой.
Тут выборка не репрезентативна. Вы выберите "мэйнстрим по мнению остатков хабравчан". Именно по этому меня лично больше интересует корреляция "выбор фреймворка" — "опыт в коммерческой разработке" — "опыт командной разработки". Это позволяет чуть по другому взглянуть на тренды. Мол Laravel и Yii выбирают в основном новички, более опытные чуваки сидят на Symfony, Zend. Есть хипстота которая не использует фреймворки, а так же опытные дядьки которые на компонентах собирают свои фреймворки под конкретную задачу.
Мэйнстрим — это бесполезная штука.
Мэйнстрим — это бесполезная штука.
Тогда вопрос как мне кажется не очень корректно задан, так как на работе я буду писать на symfony2, а для себя на laravel5. И я подумал что спрашивают именно про меня и про мои предпочтения, и я ответил laravel5.
подразумевается, что стадия сравнения, споров и выбора уже прошла, и тимлид или команда или бизнес решили: по факту будем писать на
В статистике интересна не итоговая цифра, а именно корреляция, о чем и говорит товарищ Fesor.
Я же маленькие личные проекты я скорее буду делать на Ayres шутки ради
Раз уж упомянули, то расскажите подробней об этом фреймворке.
Ну это фреймворк-пример, собранный из разных компонентов вокруг проекта amphp. По сути этот не фреймворк даже, а просто http/websocket сервер на php, построенный на корутинах. Что-то типа node.js + async/await. В рамках этого проекта уже реализованы библиотеки для удобной неблокируемой работы с сокетами, http, есть неблокирующие mysql и psql драйвера и т.д.
Если вы помните такой проект как reactphp — то тут примерно то же самое, но можно писать в синхронном стиле за счет использования корутин и промисов. Никаких колбэков.
Если вы помните такой проект как reactphp — то тут примерно то же самое, но можно писать в синхронном стиле за счет использования корутин и промисов. Никаких колбэков.
интересно, а если речь о SASS/SCSS заходит то вы сразу на Ruby начинаете писать?
То есть, Вы хотите сказать что если язык развивается и на нем можно новые вещи делать то это плохо и все равно нужно другой инструмент брать?
Просто, я как-то не заметил развития php в сторону асинхронности.
yield и корутины доступны в php с 2012-ого года, реализация event loop итого дольше. stream_select — с версии 4.3. Что еще нужно?
А вот разные, сторонние костыли пытающиеся реализовать асинхронность
это называется распределение задач по обработчикам, никаких "кастылей", просто возможность гибко масштабироваться. Сегодня мы держим все воркеры в одном процессе, а завтра этим занимается класстер. Или MPI предлагаете юзать?
расскажите пожалуйста, как использовать корутины для асинхронности, насколько я понял, поток программы все равно остается один?
Это по научному называется "мультиплексирование потока выполнения".
Если мы например возьмем go и его горутины, но внутри это будет все те же корутины, просто пул оных будет разнесен еще и по нескольким потокам. Это нужно для минимизации эффекта переключения контекста, то есть производительность при сотне полноценных тредов будет сильно ниже чем корутины + малое количество тредов.
Собственно точно так же работает nginx, где в каждом воркере запущен event loop, который работает точно так же как корутины. Профит от корутин в сравнении с обычным event loop в том что мы можем писать код абсолютно в синхронном стиле без единого колбэка. Пример:
Это простенький echo-сервер на PHP написанный с использованием корутин. В C# есть еще более удобная штука, async/await, которая по сути является сахаром над корутинами. В javascript например оно заимплеменчено в рамках es2016.
Если мы например возьмем go и его горутины, но внутри это будет все те же корутины, просто пул оных будет разнесен еще и по нескольким потокам. Это нужно для минимизации эффекта переключения контекста, то есть производительность при сотне полноценных тредов будет сильно ниже чем корутины + малое количество тредов.
Собственно точно так же работает nginx, где в каждом воркере запущен event loop, который работает точно так же как корутины. Профит от корутин в сравнении с обычным event loop в том что мы можем писать код абсолютно в синхронном стиле без единого колбэка. Пример:
<?php // basic server
require __DIR__ . '/vendor/autoload.php';
use Amp as amp;
use Amp\Socket as socket;
amp\run(function () {
$socket = socket\listen("tcp://127.0.0.1:1337");
$server = new socket\Server($socket);
echo "listening for new connections ...\n";
while ($client = (yield $server->accept())) {
amp\resolve(onClient($client));
}
});
// Generator coroutine is a lightweight "thread" for each client
function onClient(socket\Client $client) {
$clientId = $client->id();
echo "+ connected: {$clientId}\n";
while ($client->alive()) {
$data = (yield $client->readLine());
echo "data read from {$clientId}: {$data}\n";
$bytes = (yield $client->write("echo: {$data}\n"));
echo "{$bytes} written to client {$clientId}\n";
}
echo "- disconnected {$clientId}\n";
}Это простенький echo-сервер на PHP написанный с использованием корутин. В C# есть еще более удобная штука, async/await, которая по сути является сахаром над корутинами. В javascript например оно заимплеменчено в рамках es2016.
Ок. И как по вашему `yield` относится к асинхронности?
Точно так же, как и event loop в node.js собственно. Принцип работы — идентичный.
Генераторы и итераторы не имеют отношения к асинхронности или многопоточности. Они вообще о другом.
Они позволяют контролировать и прерывать поток выполнения так как хочется того разработчику. В приведенном вами примере с нодой генераторы используются для реализации полифила async/await например.
event loop. Да есть. Но это еще не асинхронность.
Дайте определение где настоящая честная асинхронность. Треды в PHP есть, но использовать треды в web в 90% случаев не имеет смысла. Golang и его горутины — это пулы корутин раскиданные по отдельным потокам и там как бы тоже не совсем честная асинхронность, хоть уже и ближе. Но мы так же можем запустить n процессов воркеров со своими пулами корутин, и получим примерно тот же эффект, просто не столь удобно.
stream_select. Вы серьезно? Вы еще форки вспоминте. Это вообще не юзабельно.
Мне кажется вы просто не знаете что это такое. Эта штука позволяет нам реализовать на низком уровне event loop.
1 из 10К пэхапешников имел опыт и честь отважно этим пользоваться.
Правильно, потому как это низкоуровневая штука. Все юзают reactphp/amphp.
Не так просто существует устойчивое мнение, что в php нет асинхронности и многопоточности.
pthreads доступен для php уже лет 10 а то и больше. Так что многопоточность есть. Но давайте учтем такую вещь как переключение контекста и подумаем еще раз — а так ли нужна ли нам многопоточность на бэкэнде.
Пока что нет. Как будет, я очень обрадуюсь.
Давайте может определимся чего мы хотим достичь. Асинхронность не нужна, нужна "неблокируемость". С этим у PHP все плохо в плане готовых бибилиотек, но проекты типа amphp радуют.
Интересно, а вы и сокеты будете на PHP подымать?
Да, у меня даже опыт такой есть. И в этом нет ничего страшного. Если надо что-то из разряда "стандартное решение" то я конечно же возьму node.js + socket.io, но говорить что нет задач под пых где нужны демоны — это чуть более чем странно.
Как бы основная проблема то в том что большая часть библиотек не оч побочные эффекты обрабатывают, и это основная беда похапэшников.
Чем лучше? Особенно, если на PHP уже реализована мощная модель домена. Переписывать на JS и синхронную часть на асинхронный манер? Поддерживать две модели одного домена на двух языках с, как минимум, разной объектной моделью?
чтобы не пришлось его преодолевать
Для того что бы выбрать оный разработчик должен быть хорошо знаком еще с пятком других фреймворков что бы делать какой-то обоснованный выбор.
А вот если задачи очень уж нестандартные, то стоит подумать о самописном проекте
При любой нестандартной задаче обычно речь идет о каких-то отдельных компонентах, либо о сложностях с отдельными компонентами которые могут возникнуть если проект выстрелит и не сразу. То есть в первую очередь фреймворк должен нас ограничивать от выстрела в ногу, но давать заменять свои части. Фреймворки уровня zend/symfony/laravel это позволяют делать. Yii скажем — нет, вы полностью завязываетесь на его инфраструктуру, но у этого тоже есть свои плюсы.
Мне не нравится трактование MVC во фреймворках.
Mediating-controller MVC, Model2? Какой из них? Классический MVC не применим в stateless-модели выполнения.
Мне в этом нравится позиция авторов Symfony:
I don't like MVC because that's not how the web works. Symfony2 is an HTTP framework; it is a Request/Response framework. That's the big deal. The fundamental principles of Symfony2 are centered around the HTTP specification.
Я тоже считаю, что AR — это некоторый антипаттерн, что не отменяет его как очень эффективную и удобную штуку. А сможете ли Вы на словах объяснить что в нём плохого? ;)
Рассказываю — AR плох тем, что смешивает работу над хранилищем (БД) с работой над моделью, что там пересекаются области ответственности непосредственно сущности и работой с базой данных, что зачастую такая модель монструозна, что… Ну т.е. проблем дофига.
Но повторюсь — оно удобно. Можно написать
Вот и все его проблемы.
Но повторюсь — оно удобно. Можно написать
User::getAll() для получения объектов всех пользователей из ресурса (таблицы, в случае с БД) пользователей и не париться. По этому его так называют те, кто смог с ним поработать и понять, что очень жирная модель, приближённая к божественному объекту — это не всегда хорошо. Хотя никто не мешает опять же разделить эти области ответственности, превратив AR модель в своеобразный репозиторий, а энтити иметь кристально чистыми, заточенными под бизнес-логику непосредственно.Вот и все его проблемы.
Эвенты никак не относятся к AR непосредственно (https://en.wikipedia.org/wiki/Active_record_pattern). Задача AR лишь записать и получить модель в бд с указанным состоянием, где объект представляет собой "слепок" состояния таблицы в нужный момент времени, а эвенты лишь следствие этих действий. Я рассказывал о проблемах паттерна в целом, а не способе решения проблем в какой-либо реализации, которая добавляет туда ещё и эвенты.
А под композицией я так понимаю имеется ввиду embeddables? Тогда вариант, вполне.
Но эти действия не отменяют того, что мы смешиваем с реализацию (
А под композицией я так понимаю имеется ввиду embeddables? Тогда вариант, вполне.
Но эти действия не отменяют того, что мы смешиваем с реализацию (
$user->name = 'Vasya'), вместо работы с бизнес-логикой ($user->rename('Vasya')). fesor давеча открыл мне глаза на подобную вроде как мелочь, которая в реальности поменяла мою картину мира.Суть в том, что большинство людей, которые используют AR, используют их как анемичные модельки, как row data gateway, и в итоге бизнес логика сущностей размазывается в лучшем случае по сервисам-менеджерам. Что по итогу приводит к тому, что из спагетти кода мы получаем лазанья код, то есть если мы хотим внести небольшие изменения не затрагивающие функционал на одном уровне, мы должны будем поменять все насквозь, от контроллера до базы данных.
давайте вспомним как вообще появился на свет паттерн Active Record. Сидели чуваки, и была у них комбинация из Domain Object + Row Data Gateway:
и все было ништяк, инкапсуляция, разделение ответственности, удобно же. А потом кто-то задумался… вот нет у меня в проекте сложной бизнес логики… я тупо данными оперирую на уровне CRUD. И выходит что для простой прослойки бизнес логики мне надо городить сверху еще одну прослойку объектов… зачем… я лучше прямо в row data gateway вынесу свою простую логику.
И так и сделали, и назвали это дело active state или active record. И для простых проектов — это мега удобно, но проекты посложнее — там уже нужно вводить domain objects, а по итогу выходит что люди начинают размазывать логику по сервисам, и иногда делают их stateful.
Альтернатива — data mapper. И я сейчас не про доктрину, ибо там намнооого больше чего есть. Я сейчас про самую примитивную реализацию. По уровню сложности — вот ни разу не сложнее active record, но вот гибкости и пространства для моневра дает чуть больше.
И проблема сейчас в том, что у людей из полноценных решений только простые примитивные реализации active record, и мегажирная доктрина. А про проекты типа spot2, analogueorm никто и не слыхивал. И в итоге у людей возникает непонимание как все эти вещи юзать. Культ карго и все такое.
class User {
private $attributes;
private function __construct($email, $password) {
// тут есть варианты что бы можно было подменять реализацию
$this->attributes = UserGateway::create();
$this->attributes->email = $email;
$this->attributes->password = $password;
}
public static function register($email, $password) {
$user = new static($email, $password);
$user->attributes->save();
}
public function makeSomeBuisnessStuff() { /** ... */ }
}и все было ништяк, инкапсуляция, разделение ответственности, удобно же. А потом кто-то задумался… вот нет у меня в проекте сложной бизнес логики… я тупо данными оперирую на уровне CRUD. И выходит что для простой прослойки бизнес логики мне надо городить сверху еще одну прослойку объектов… зачем… я лучше прямо в row data gateway вынесу свою простую логику.
И так и сделали, и назвали это дело active state или active record. И для простых проектов — это мега удобно, но проекты посложнее — там уже нужно вводить domain objects, а по итогу выходит что люди начинают размазывать логику по сервисам, и иногда делают их stateful.
Альтернатива — data mapper. И я сейчас не про доктрину, ибо там намнооого больше чего есть. Я сейчас про самую примитивную реализацию. По уровню сложности — вот ни разу не сложнее active record, но вот гибкости и пространства для моневра дает чуть больше.
И проблема сейчас в том, что у людей из полноценных решений только простые примитивные реализации active record, и мегажирная доктрина. А про проекты типа spot2, analogueorm никто и не слыхивал. И в итоге у людей возникает непонимание как все эти вещи юзать. Культ карго и все такое.
что AR — антипаттерн.
Ну вот… на счет того что это антипаттерн не соглашусь, а вот то что его оверюзят там где не надо — это факт. Доктрина — это противоположная сторона — это удобный инструмент для прототипирования и быстрой разработки.
тут другое дело что для половины проектов и ORM в общем-то не нужен. Достаточно table gateway организовать что бы sql не размазывался по проекту. Ну и с учетом трендов типа использования документно-ориентированных баз данных и т.д. достаточно простого мэппера какого.
Развелось так званых программистов, не умеющих писать SQL.
Почему же? Просто мне вот не особо хочется париться по поводу того, какую базу данных выбрать например. В итоге я сначала накидываю логику приложения а потом думаю, какая модель данных тут подходит больше и что выбрать. Скажем если я выберу mongodb — мне по сути ничего вообще не надо. Выберу реляционку — прикручу доктрину, я всеравно все выборки на чтение в большинстве случаев делаю через dbal.
Мне не нравятся активрекорды, доктрины и прочий мусор.
А битикс не мусор?
1) Почему же, я довольно часто сталкивался с кейсом, когда локально используется sqlite, а на дев. сервере и боевом уже mysql и прочие. Причина одна, небольшой проектик, вроде блога или лендинга для исправления мелких багов проще развернуть на простом окружении — php + builtin + sqlite, вместо конфигурирования php + apache + mysql.
2) PDO не меняет SQL синтаксис. ORM и билдеры это делают, подстраивая его под нужную БД. Не весь конечно, но большинство популярных задач оно решает.
2) PDO не меняет SQL синтаксис. ORM и билдеры это делают, подстраивая его под нужную БД. Не весь конечно, но большинство популярных задач оно решает.
Не так давно нужно было развернуть небольшой (на самом деле громадный) проект у жены на ноуте, чтоб она подправила там верстку. Стоял у нее Windows и я попробовал Open Server. Как оказалось, теперь без доната эта штука качается с обрезанной скоростью, весит 180 метров, а устанавливается (распаковывается) минут 15.
Я около часа ставит Open Server, затем еще час собирал зависимости и настраивал окружение. В результате плюнул на все и следующим утром накатил Ubuntu Linux. В одну команду поставил окружение (PHP Web-server + bowerphp + sqlite) и отдал рабочий проект.
Этот же проект надо будет передать другому верстальщику, у которого MacOS и нет Open Server. Предложите ему перейти на Win + Open Server? )
Я около часа ставит Open Server, затем еще час собирал зависимости и настраивал окружение. В результате плюнул на все и следующим утром накатил Ubuntu Linux. В одну команду поставил окружение (PHP Web-server + bowerphp + sqlite) и отдал рабочий проект.
Этот же проект надо будет передать другому верстальщику, у которого MacOS и нет Open Server. Предложите ему перейти на Win + Open Server? )
vagrant, docker?
Может у вас нищебродный интернет и ноут? :)
Попробуйте сами скачать с официального сайта без доната.
Какие еще зависимости?
У крупные проектов есть такая вещь, как зависимости.
Будто mysql так сложно поставить :)
Ну как сказать, вот примерный порядок действий для Win:
- Скачать
- Распаковать
- Установить
- Сконфигурировать (имя/пароль админа)
Зачем все это когда можно использовать sqlite с теми же возможностями (естественно ограниченными) для локальной разработки, которая развернется с выполнением install.sh?
Предложите ему перейти на Ubuntu и то, что Вы ставили
Боюсь он пошлет вас и меня очень далеко и останется сидеть на чем сидел.
PHP на винде практичезки из коробки работает, кстати. Web Platform Installer в помощь.
PHP на винде практичезки из коробки работает
Почему "практичезки" из коробки? Он вполне полноценно работает из коробки на винде.
Web Platform Installer
Microsoft Web Platform Installer — бесплатное приложение, которое упрощает загрузку, установку и обновление всех компонентов веб-платформы Microsoft, включая Internet Information Services (IIS), SQL Server Express, .NET Framework и Visual Web Developer
А можно мне просто PHP с драйвером PDO_SQLite?
Но по факту большинство не меняет базу. Да и есть PDO. :)
Ну… разные бывают задачи. А еще есть микросервисы, когда весь проект — это на самом деле много мелких проектов, и у каждого может быть своя база специфичная под нужды.
Грустно это слышать в 2016-ом году...
У композера еще есть модный автозагрузчик.
но мне как-то не хотелось писать для чужих либ автозагрузчик в композере
Соль в том, что composer сам пишет автозагрузчик.
для чужих либ автозагрузчик в композере
А чужих либ нет в композере? Может есть уже получше альтернативы?
Знаете, я вот тоже bower-ом не пользуюсь… npm и все такое. а bower мертвый.
А зачем использовать 2 инструмента (npm и сабж), выполняющих одинаковую задачу?
Сейчас js становится всё больше и больше изоморфным, граница между платформами (браузер, нода, etc) всё больше размывается и нет смысла разделять библиотеки на фронт и бэк.
Сейчас js становится всё больше и больше изоморфным, граница между платформами (браузер, нода, etc) всё больше размывается и нет смысла разделять библиотеки на фронт и бэк.
Ну например если фронтэнд — это просто jquery и плагины, то тут преимущества npm перед bower уже не так очевидны.
А если frontend зависимости собираются в один файл внутри какого нить gulp и нужно четко разделять frontend и develop зависимости, то таки bower решает.
Вот как раз таки npm тут решает больше.
А уже есть хорошая замена столь ненавистному мною main-bower-files в npm?
не использоваь bower, использовать для сборки бандлеры вроде webpack или system.js (ну или любой другой бандлер).
А если автоматическая сборка недопустима и нужно точно указать какие зависимости относятся к frontend, а какие к dev?
Поясните, для меня это какая-то надуманная ситуация.
Был опыт невозможности использования автосборщиков на подобе webpack (связано с параноидальной безопастностью начальства), потому только автоматизированная, но все же подконтрольная сборка.
связано с параноидальной безопастностью начальства
Я… даже не знаю что сказать. Я бы на вашем месте просто бы заюзал webpack, а в качестве шапочки из фольги просто запускал бы сборщик в docker-контейнере без доступа к сети.
Дело не в сборке, а в ссылках внутри js файлов. Нужно было собрать проект так, чтобы пользователи без соответствующего доступа не могли любым способом найти js файлы, которые для них не предназначались. Webpack собирает проект с записью ссылок на chunks внутрь самих js файлов, а этого нельзя было использовать. Короче запутанная там история.
А где же CodeIgniter?
Symfony 3
Уважаемые профессионалы, а можете развернуто сравнить Laravel 5 vs. Yii 2 vs. Symfony 2? (для личных проектов, которые могут быть как маленькими так и достаточно большими)
Silex
поддержу)) который еще и оброс полезными библиотеками)
Который превращается в ходе разработки в тот же symphony 2 но на костылях? ) Спрашиваю ради интереса, потому что когда делал на нём проект, пришлось чуть ли не половину компонентов symphony перетащить, ещё и настроить верно, чтобы не конфликтовали с друг-другом. Были проблемы с последовательностью инициализации последних.
С выходом Symfony 2.8 сайлекс не нужен вовсе.
Почему? Он стал более легковесным и конфигурируемым на этапе установки? Где об этом почитать можно?
Спасибо выглядит неплохо, но не совсем то, что мне нужно. Иногда микрофреймворк нужен не для микроприложений, а для слабой связности компонентов и низкого оверхеда, чтобы интегрировать в имеющийся код.
Мне надо что-то вроде 50% функционала стандартного Symfony 2. То есть с yaml-роутингом и конфигурационными файлами, symfony-translate, twig и DI хоть в каком-нибудь виде. Мне показалось проще допилить Silex до этой комплектации, чем урезать Symfony. По крайней мере в случае с Silex накоплена обширная база знаний.
P.S. я вспомнил еще один нюанс с компонентами 2.8 — негарантированная поддержка php 5.3, что опять же существенно для меня в настоящий момент, увы.
Мне надо что-то вроде 50% функционала стандартного Symfony 2. То есть с yaml-роутингом и конфигурационными файлами, symfony-translate, twig и DI хоть в каком-нибудь виде. Мне показалось проще допилить Silex до этой комплектации, чем урезать Symfony. По крайней мере в случае с Silex накоплена обширная база знаний.
P.S. я вспомнил еще один нюанс с компонентами 2.8 — негарантированная поддержка php 5.3, что опять же существенно для меня в настоящий момент, увы.
а для слабой связности компонентов и низкого оверхеда, чтобы интегрировать в имеющийся код.
Ну тут да, тут проще брать отдельные компоненты даже, а не микрофреймворки. Хотя если надо быстро накидать апишку — то почему бы и нет.
Мне показалось проще допилить Silex до этой комплектации
Мне тоже так казалось пока не попробовал, в итоге теложвижений было много больше, а урезать симфони — без проблем. Правда у меня на этих проектах небыло сильно требований по быстродействию и т.д. потому чуть оверхэда добавляло. Но опять же в режиме микроядра все должно быть ок.
негарантированная поддержка php 5.3, что опять же существенно для меня в настоящий момент, увы.
Чтож, могу лишь посочувствовать. У меня подавляющее большинство проектов на 5.6 и все за последние месяца 4 на php7.
silex — деревяшка, к которой легко приделывается термоядерный реактор, который умеет печь блины и делать конфетки. для меня, как любителя, делает еще и офигенный кофе :)
Вы не поверите, будете смеяться, но CakePHP. Как то привык уже :-)
Кмк, принятие PSR в последние годы направляет PHP в сторону модулей/компонентов, а не фреймворков. Сейчас легко можно собрать фреймворк под свои задачи, без мук выбора.
Так современные фреймворки как раз и компонентные. С таким же успехом можно взять симфони или ларавельку и разобрать на составляющие. Будет почти тоже самое, но в обратную сторону.
Если разобрать ларавельку, то получится симфони :)
Я про то и говорю, что понятие фреймворк теперь это набор компонентов и нет особой разницы, кто эти компоненты воедино собрал и назвал новым именем.
Кроме того, чтобы привязываться к фреймворку и вникать в его абстракции, нужно хорошо подумать, что будет с ним через несколько лет. Для работы на аутсорс это важнее, свой проект во фреймворке, скорее всего, не нуждается.
Я про то и говорю, что понятие фреймворк теперь это набор компонентов и нет особой разницы, кто эти компоненты воедино собрал и назвал новым именем.
Кроме того, чтобы привязываться к фреймворку и вникать в его абстракции, нужно хорошо подумать, что будет с ним через несколько лет. Для работы на аутсорс это важнее, свой проект во фреймворке, скорее всего, не нуждается.
Slim 3
Phalcon на PHP7
Мне кажется, что фалькон умер еще до выхода PHP7. А теперь и подавно. Не успевают писать зефир и баги в фальконе править, слишком мало контрибьюторов.
Да многим после выхода PHP7 он не нужен, т.к. разница в скорости уже не такая значительная, а ограничений получается много.
Да многим после выхода PHP7 он не нужен, т.к. разница в скорости уже не такая значительная, а ограничений получается много.
Это всё из-за кризиса. Из разряда, как нам на одном сервере запустить три-четыре «фейсбука»? А флакон, всё-таки, несмотря на все свои недостатки, наименее требовательный к ресурсам среди вышеперечисленных вариантов.
Ну я как бы могу на go свои проекты писать и выйдет ни чуть не медленнее, какой мне смысл брать фреймворк на Си или на компилируемом в Си языке?
Очень правильное решение — писать на go. Как только создадут опрос «На каком фреймворке вы будете писать Go приложение в 2016 году», я обязательно выскажусь по-этому поводу. Но, поскольку, мы обсуждаем PHP, я вынужден воздержаться от комментария о смысле использования Go вместо Phalcon.
Да поймите, если у меня внезапно будут задачи где нужны прилиные RPS, и, мжет у нас уже есть существующее приложение на PHP, устраняем сайдэффекты меджу запросами и впиливаем поверх всего php-pm. В итоге время бутстраппинга фреймворка невилировано, а скорость PHP7 позволяет сравнивать время работы зефрики и просто PHP. Одно но — пых теперь не умирает, а это требует чуть более адекватного уровня. Как никак средне-статистический похапэшник понятия не имеет что такое сайд эффекты и какие из них есть в его коде.
TYPO3
Тут важно с какой целью задавался вопрос. Если с позиции «взять какой-то новый фреймворк на изучение или продвинуться в текущем»? То можно посмотреть по вакансиям. «Самый-самый» тренд может и не словите, но в качестве прогноза на ближайшие пару лет сойдёт. Без хлеба точно не останешься.
Итак.
Посмотрел сейчас на jobs.tut.by (тот же hh.ru, только для Беларуси)
Из 221-й вакансии, где требуется (упоминается) PHP
[ Фреймфорки ]
В 46-и вакансиях в требованиях упоминается Symfony
В 25-и Yii
В 29-и Zend Framework (возможно немного меньше, если в одном объявлении использованы обе формы: 20 Zend + 9 ZF)
В 19-и Laravel
В 5-и CakePHP
В 4-х CodeIgniter
[ CMS ]
В 33-и Bitrix
В 24-х Magento
В 21-и Drupal
В 17-и Joomls
В 17-и WordPress
Из подсчёта выкинуты Маркетологи, SEO-специалисты и пр. В одном и том же объявлении может быть упомянуто несколько фреймворков/CMS. Но общее представление можно составить.
Ещё можно воспользоваться wordstat.yandex.ru и посмотреть количество запросов (уровень проявленного интереса) и, возможно, динамику его изменения.
Итак.
Посмотрел сейчас на jobs.tut.by (тот же hh.ru, только для Беларуси)
Из 221-й вакансии, где требуется (упоминается) PHP
[ Фреймфорки ]
В 46-и вакансиях в требованиях упоминается Symfony
В 25-и Yii
В 29-и Zend Framework (возможно немного меньше, если в одном объявлении использованы обе формы: 20 Zend + 9 ZF)
В 19-и Laravel
В 5-и CakePHP
В 4-х CodeIgniter
[ CMS ]
В 33-и Bitrix
В 24-х Magento
В 21-и Drupal
В 17-и Joomls
В 17-и WordPress
Из подсчёта выкинуты Маркетологи, SEO-специалисты и пр. В одном и том же объявлении может быть упомянуто несколько фреймворков/CMS. Но общее представление можно составить.
Ещё можно воспользоваться wordstat.yandex.ru и посмотреть количество запросов (уровень проявленного интереса) и, возможно, динамику его изменения.
В России немного иначе. Неделю назад делал срезы по вакансиям на hh.ru, к сожалению данные остались только по последнему, но пропорции приблизительно те же, что и по всем php-программистам без учёта зп (постараюсь вечером найти эти результаты).
Итак, отфильтровал все все php-вакансии с зп >= 140к, получилось их — 90, а потом по ним искал упоминания в описании:
ниже результаты (поисковая фраза — количество вакансий, в которых присутствовала)
yii — 47
yii2 — 29
symfony — 19
symfony2 — 19
zend — 11
mysql — 70
redis — 33
mongodb — 23
postgresql — 16
memcache — 11
linux — 20
docker — 17
composer — 15
git — 58
svn — 9
Итак, отфильтровал все все php-вакансии с зп >= 140к, получилось их — 90, а потом по ним искал упоминания в описании:
ниже результаты (поисковая фраза — количество вакансий, в которых присутствовала)
yii — 47
yii2 — 29
symfony — 19
symfony2 — 19
zend — 11
mysql — 70
redis — 33
mongodb — 23
postgresql — 16
memcache — 11
linux — 20
docker — 17
composer — 15
git — 58
svn — 9
Drupal добавьте тогда уж)
На Symfony 3, естественно
На всякий случай, когда будете считать статистику: я нажал на другое, т.к. все же между sf2 и sf3 приличное количество отличий.
Нет там больших отличий. Ломает обратную совместимость? Да. Сложно обновиться с 2.8 до 3? Нет. Различий в версиях минимум.
Можете назвать "приличное количество различий" между sf2.8 и sf3.0 кроме удаления помеченного депрекейтед функционала? Я вот как-то не могу. Новая структура директорий? Я ее с версии 2.6 юзаю.
Скорее всего вы просто не используете огромное количество возможностей Symfony.
Вот листинг того, что надо менять при переходе с 2.x на 3.0: https://github.com/symfony/symfony/blob/master/UPGRADE-3.0.md.
Но как минимум хотя бы с конструкторами форм вы должны были столкнуться (теперь там не экземпляры FormType, а FormType::class), измененными валидаторами объектов и измененными Yaml конфигами (например, вызов колбеков после конструктора, описание роутов).
Так же есть незначительные, но все же изменения в ContainerBuilder-е, bundle compiler-е, dependecy injection, если вы делаете свои бандлы кастомно прекомпилируемыми.
Понятно, что это не кардинальные изменения по сравнению с 1.x -> 2.x, но если проект серьезный, то несколько дней правок обеспечены.
Вот листинг того, что надо менять при переходе с 2.x на 3.0: https://github.com/symfony/symfony/blob/master/UPGRADE-3.0.md.
Но как минимум хотя бы с конструкторами форм вы должны были столкнуться (теперь там не экземпляры FormType, а FormType::class), измененными валидаторами объектов и измененными Yaml конфигами (например, вызов колбеков после конструктора, описание роутов).
Так же есть незначительные, но все же изменения в ContainerBuilder-е, bundle compiler-е, dependecy injection, если вы делаете свои бандлы кастомно прекомпилируемыми.
Понятно, что это не кардинальные изменения по сравнению с 1.x -> 2.x, но если проект серьезный, то несколько дней правок обеспечены.
теперь там не экземпляры FormType, а FormType::class
Нет, теперь там FQCN вместо alias.
измененными валидаторами объектов
Уточните, пожалуйста. Мои правила в sf3 такие же, как и в sf2.
измененными Yaml конфигами
Это правится один раз.
По поводу FQCN согласен, но цитирую UPGRADE-3.0.md от Symfony:
...the FormFactory::create*() methods is not supported anymore. Pass the fully-qualified class name of the type instead.
Before: $form = $this->createForm(new MyType());
After: $form = $this->createForm(MyType::class);
Поэтому не совсем понятно, где именно вы нашли то, к чему относилось «Нет».
...the FormFactory::create*() methods is not supported anymore. Pass the fully-qualified class name of the type instead.
Before: $form = $this->createForm(new MyType());
After: $form = $this->createForm(MyType::class);
Поэтому не совсем понятно, где именно вы нашли то, к чему относилось «Нет».
В любом проекте при переходе с чего-то одного на что-то другое все правится 1 раз, поэтому это странный аргумент. По факту после апдейта на 3.0 даже с 2.8 значительная часть не «hello world» проектов не работает корректно, и да, необходимо, пробежаться везде и по одному разу в каждом моменте подправить. Т.е. нет 100% совместимости. Но, еще раз, естественно, это не переезд на другой фреймворк (включая sf1.4).
По валидаторам:
The PHP7-incompatible constraints (Null, True, False) and their related validators (NullValidator, TrueValidator, FalseValidator) have been removed in favor of their Is-prefixed equivalent.
The class Symfony\Component\Validator\Mapping\Cache\ApcCache has been removed in favor of Symfony\Component\Validator\Mapping\Cache\DoctrineCache.
The constraints Optional and Required were moved to the Symfony\Component\Validator\Constraints\ namespace. You should adapt the path wherever you used them.
The option «methods» of the Callback constraint was removed. You should use the option «callback» instead. If you have multiple callbacks, add multiple callback constraints instead.
The interface ValidatorInterface was replaced by the more powerful interface Validator\ValidatorInterface. The signature of the validate() method is slightly different in that interface and accepts a value, zero or more constraints and validation group. It replaces both validate() and validateValue() in the previous interface.
The interface ValidationVisitorInterface and its implementation ValidationVisitor were removed. The implementation of the visitor pattern was flawed. Fixing that implementation would have drastically slowed down the validator execution, so the visitor was removed completely instead.
Along with the visitor, the method accept() was removed from MetadataInterface.
The interface MetadataInterface was moved to the Mapping namespace.
The interface PropertyMetadataInterface was moved to the Mapping namespace.
The interface PropertyMetadataContainerInterface was moved to the Mapping namespace and renamed to ClassMetadataInterface.
The interface ClassBasedInterface was removed. You should use Mapping\ClassMetadataInterface instead:
The class ElementMetadata was renamed to GenericMetadata.
The interface ExecutionContextInterface and its implementation ExecutionContext were moved to the Context namespace.
The method addViolationAt() was removed. You should use buildViolation() instead.
The methods validate() and validateValue() were removed. You should use getValidator() together with inContext() instead.
The parameters $invalidValue, $plural and $code were removed from addViolation(). You should use buildViolation() instead. See above for an example.
The method getMetadataFactory() was removed. You can use getValidator() instead and use the methods getMetadataFor() or hasMetadataFor() on the validator instance.
The interface GlobalExecutionContextInterface was removed. Most of the information provided by that interface can be queried from Context\ExecutionContextInterface instead.
The interface MetadataFactoryInterface was moved to the Mapping\Factory namespace along with its implementations BlackholeMetadataFactory and ClassMetadataFactory. These classes were furthermore renamed to BlackHoleMetadataFactory and LazyLoadingMetadataFactory.
The option $deep was removed from the constraint Valid. When traversing arrays, nested arrays are always traversed (same behavior as before). When traversing nested objects, their traversal strategy is used.
The method ValidatorBuilder::setPropertyAccessor() was removed. The validator now functions without a property accessor.
The methods getMessageParameters() and getMessagePluralization() in ConstraintViolation were renamed to getParameters() and getPlural().
The class Symfony\Component\Validator\DefaultTranslator was removed. You should use Symfony\Component\Translation\IdentityTranslator instead.
Это все изменения в именовании классов, их методов и параметров методов в неймспейсе Symfony\Component\Validator. Странно, что вы не столкнулись с тем, что даже те же Optional и Required валидаторов уже нет на прошлом месте.
По валидаторам:
The PHP7-incompatible constraints (Null, True, False) and their related validators (NullValidator, TrueValidator, FalseValidator) have been removed in favor of their Is-prefixed equivalent.
The class Symfony\Component\Validator\Mapping\Cache\ApcCache has been removed in favor of Symfony\Component\Validator\Mapping\Cache\DoctrineCache.
The constraints Optional and Required were moved to the Symfony\Component\Validator\Constraints\ namespace. You should adapt the path wherever you used them.
The option «methods» of the Callback constraint was removed. You should use the option «callback» instead. If you have multiple callbacks, add multiple callback constraints instead.
The interface ValidatorInterface was replaced by the more powerful interface Validator\ValidatorInterface. The signature of the validate() method is slightly different in that interface and accepts a value, zero or more constraints and validation group. It replaces both validate() and validateValue() in the previous interface.
The interface ValidationVisitorInterface and its implementation ValidationVisitor were removed. The implementation of the visitor pattern was flawed. Fixing that implementation would have drastically slowed down the validator execution, so the visitor was removed completely instead.
Along with the visitor, the method accept() was removed from MetadataInterface.
The interface MetadataInterface was moved to the Mapping namespace.
The interface PropertyMetadataInterface was moved to the Mapping namespace.
The interface PropertyMetadataContainerInterface was moved to the Mapping namespace and renamed to ClassMetadataInterface.
The interface ClassBasedInterface was removed. You should use Mapping\ClassMetadataInterface instead:
The class ElementMetadata was renamed to GenericMetadata.
The interface ExecutionContextInterface and its implementation ExecutionContext were moved to the Context namespace.
The method addViolationAt() was removed. You should use buildViolation() instead.
The methods validate() and validateValue() were removed. You should use getValidator() together with inContext() instead.
The parameters $invalidValue, $plural and $code were removed from addViolation(). You should use buildViolation() instead. See above for an example.
The method getMetadataFactory() was removed. You can use getValidator() instead and use the methods getMetadataFor() or hasMetadataFor() on the validator instance.
The interface GlobalExecutionContextInterface was removed. Most of the information provided by that interface can be queried from Context\ExecutionContextInterface instead.
The interface MetadataFactoryInterface was moved to the Mapping\Factory namespace along with its implementations BlackholeMetadataFactory and ClassMetadataFactory. These classes were furthermore renamed to BlackHoleMetadataFactory and LazyLoadingMetadataFactory.
The option $deep was removed from the constraint Valid. When traversing arrays, nested arrays are always traversed (same behavior as before). When traversing nested objects, their traversal strategy is used.
The method ValidatorBuilder::setPropertyAccessor() was removed. The validator now functions without a property accessor.
The methods getMessageParameters() and getMessagePluralization() in ConstraintViolation were renamed to getParameters() and getPlural().
The class Symfony\Component\Validator\DefaultTranslator was removed. You should use Symfony\Component\Translation\IdentityTranslator instead.
Это все изменения в именовании классов, их методов и параметров методов в неймспейсе Symfony\Component\Validator. Странно, что вы не столкнулись с тем, что даже те же Optional и Required валидаторов уже нет на прошлом месте.
Алгоритм простой — апаемся на sf 2.8, все те вещи в списке начинают писать в логах о том что что-то депрекейтед юзается, планомерно выпиливаем старое и пользуемся всеми плюшками sf3 сохраняя обратную совместимость. И как только мы подчистили все — апаемся на тройку.
То есть если не пропускать обновление на 2.8 то менять придется не много.
То есть если не пропускать обновление на 2.8 то менять придется не много.
Вот здесь соглашусь полностью.
Просто Symfony 2 не есть именно Symfony 2.8. Т.к. 2.8 — это вообще спец. версия для подготовки к переходу на 3.0. В голосовании же идет речь просто про 2.х, т.е. в том числе 2.0. А 2.0 от 3.0 отличается серьезно, и список изменений очень не маленький.
Мне недавно довелось переводить 2.4 на 3.0 один очень серьезный проект. Так вот, только зачистка на 2.8 заняла 3 дня.
Просто Symfony 2 не есть именно Symfony 2.8. Т.к. 2.8 — это вообще спец. версия для подготовки к переходу на 3.0. В голосовании же идет речь просто про 2.х, т.е. в том числе 2.0. А 2.0 от 3.0 отличается серьезно, и список изменений очень не маленький.
Мне недавно довелось переводить 2.4 на 3.0 один очень серьезный проект. Так вот, только зачистка на 2.8 заняла 3 дня.
Один большой на YII2 с PHP7 и Postgresql
И один небольшой на Drupal
И один небольшой на Drupal
Если Битрикс фреймворк, тогда почему отсутствует MODX Revolution?
Симфонии 3 куда тыкать?
Я сейчас пишу на Yii2 Advanced. Мое мнение, что Yii2 вырос после обновления из Yii1.
Интересно что вы скажите если для разнообразия попишите на других фреймворках. Вот просто ради расширения кругозора. Возможно ваши проекты на Yii так же станут лучше за счет нового опыта.
Очень заметно вырос. Делал проекты на Yii1, было ощущение какой-то инопланетной логики. Недавно закончил проект на Yii2 — всё очень просто и понятно. Не исключаю, что это моя квалификация поднялась, но всё-таки по ощущениям гораздо удобней стало работать.
А с какими фреймворками у вас еще опыт есть? ибо… ваше описание не говорит ровным счетом ничего на самом деле. Скажем, есть люди которые довольны своей производительностью труда используя какие-то инструменты. Из них половине повезло с задачами, а вторая половина просто не знает что можно эффективнее расходовать время. Ну то есть… для меня Yii слишком сильно сковывает в том как делать дела. И мне интересно какие дела делают те, что у них все хорошо.
Раз уж зашел разговор про сравнение фреймворков. Я пару раз начинал изучать laravel, но как говорится "ниасилил" (может потом как-нибудь еще поразбираюсь). То что не понравилось по сравнению с Yii:
Генератор HTML для форм надо ставить отдельно. На это есть свои причины, но неудобно.
Для работы с ассетами надо использовать elixir, для elixir надо ставить node.js, нода грузит кучу модулей, которые занимают много места, и к тому же делает слишком большую вложенность папок node_modules, на что Windows ругается при удалении.
Статические обращения через фасады. Например, в обучающем примере есть вызов
Захочешь посмотреть, как этот класс Redirect устроен, какие функции в нем еще есть, или может в документации что-то не понял, ищешь по исходникам и находишь:
А класс на самом деле называется Redirector.
Из-за этого автокомплит в IDE не работает. Для автокомплита можно поставить отдельный пакет, но там просто заглушки, поэтому к месту реального объявления все равно не перейти.
Генератор модели по таблице и генератор CRUD в Yii тоже удобная штука, позволяет быстро создать минимальный рабочий код. Особенно если сделать свой генератор, который генерирует в верстке выпадающие списки на основе foreign keys. Для laravel вроде тоже есть какие-то пакеты, которые можно поставить отдельно, но я с ними не работал, поэтому ничего сказать не могу.
На мой взгляд, Yii хорошо подходит для разработки в одиночку небольших и средних проектов, у него неплохая документация и более-менее понятная архитектура, в которой можно разобраться просто по исходникам.
Генератор HTML для форм надо ставить отдельно. На это есть свои причины, но неудобно.
Для работы с ассетами надо использовать elixir, для elixir надо ставить node.js, нода грузит кучу модулей, которые занимают много места, и к тому же делает слишком большую вложенность папок node_modules, на что Windows ругается при удалении.
Статические обращения через фасады. Например, в обучающем примере есть вызов
Redirect::route().Захочешь посмотреть, как этот класс Redirect устроен, какие функции в нем еще есть, или может в документации что-то не понял, ищешь по исходникам и находишь:
class Redirect extends Facade
{
protected static function getFacadeAccessor()
{
return 'redirect';
}
}А класс на самом деле называется Redirector.
Из-за этого автокомплит в IDE не работает. Для автокомплита можно поставить отдельный пакет, но там просто заглушки, поэтому к месту реального объявления все равно не перейти.
Генератор модели по таблице и генератор CRUD в Yii тоже удобная штука, позволяет быстро создать минимальный рабочий код. Особенно если сделать свой генератор, который генерирует в верстке выпадающие списки на основе foreign keys. Для laravel вроде тоже есть какие-то пакеты, которые можно поставить отдельно, но я с ними не работал, поэтому ничего сказать не могу.
На мой взгляд, Yii хорошо подходит для разработки в одиночку небольших и средних проектов, у него неплохая документация и более-менее понятная архитектура, в которой можно разобраться просто по исходникам.
Сейчас все больше проектов уходят в сторону SPA, где класс форм больше не нужен, а тот самый elixir приходится к месту, так как есть возможность подключить такие штуки как babel.
Facade в Laravel это просто доступ к классу в контейнере по имени, в данном случае имя в контейнере 'redirect'.
CRUD меняется от проекта к проекту, и как правило занимает время только на начальном этапе, поэтому нет смысла выносить это в функционал, да и как правило для таких проектов подойдут обычные CMS или CMF.
Использовать что Laravel, что Symfony в PHPStorm без плагинов почти не возможно, так что не вижу в этом ничего особенного.
Facade в Laravel это просто доступ к классу в контейнере по имени, в данном случае имя в контейнере 'redirect'.
CRUD меняется от проекта к проекту, и как правило занимает время только на начальном этапе, поэтому нет смысла выносить это в функционал, да и как правило для таких проектов подойдут обычные CMS или CMF.
Использовать что Laravel, что Symfony в PHPStorm без плагинов почти не возможно, так что не вижу в этом ничего особенного.
А в каких задачах Yii вас сковывает?
Очень понравился Slim и PHPixie за их минималистичность.
Если подвести промежуточный итог, то понравился ответ kanstantsin https://habrahabr.ru/post/280694/#comment_8834966, сегодня используя composer можно собрать нужный функционал из отдельных, хорошо зарекомендовавших себя, библиотек, например на базе микрофреймворка.
Часто нет лишней недели на создание архитектуры из кусочков, проще использовать:
php composer.phar create-project --stability="dev" zendframework/skeleton-application path/to/installДа там как бы за пару часов можно сделать… PHP-DI + PSR-7 + какой FastRoute + PSR-3 + Doctrine2 и готов полноценный фреймворк.
Не думаю что за пару часов можно перечисленное вами сделать, если ранее вы этого еще не делали (если делали, то это уже ваш личный фреймворк и "не считается"), а ведь все что вы наделаете нужно еще "протестировать временем", а потом не раз переписать, перекостылись, перепере. Я обожаю "сборные" фреймворки (даже есть собственное решение в этой области), но очень часто хватает какого нить ZF2, что наводит на мысли.
протестировать временем
Вы ничего не пишите, вы только берете готовые компоненты и связываете их вместе через тот же php-di. Все то что я перечислил это либо рекомендованные стандарты (PSR) либо популярные реализации (FastRoute юзают в половине микрофреймворков). Да и потом, заварачиваем все в свои адаптеры и заменяем по необходимости отдельные компоненты.
То есть реально сделать простенький фреймворк за пару часов, просто под задачу. Конечно у вас уже должен быть опыт работы с отдельными компонентами, которые будут составлять его, иначе смысла в этом нет как бы.
В целом же я лично ленивый и потому просто для мелких проектов беру sf3.0 в режиме микроядра а для проектов побольше — просто свою сборку sf3.
Вы ничего не пишите, вы только берете готовые компоненты и связываете их вместе через тот же php-di.
А давно инстанциация всего набора необходимых в приложении классов == созданию архитектуры приложения? Про конфигурирование, взаимодействие, системное тестирование и подобную муть вы решили не упоминать? А какую модель роутинга вы выбирите? А ваше приложение будет поддерживать RESTful API, или только классические GET/POST HTTP запросы с возвратом HTML? А как вы будете решать проблему дублирования кода представления? А если в приложении планируется рендеринг ответа в виде HTML кода, но будет много JS на странице, как вы это решите? А (подставьте любой другой архитектурный вопрос)?
То есть реально сделать простенький фреймворк за пару часов, просто под задачу
Composer + Github помогут для проекта любого размера
Мы о проектах любого размера.
В целом же я лично ленивый и потому просто для мелких проектов беру sf3.0 в режиме микроядра а для проектов побольше — просто свою сборку sf3
Замечательно что у вас есть готовые решения )
созданию архитектуры приложения?
А давно архитектура приложения = фреймворк? Это ж совершенно разные вещи.
Про конфигурирование, взаимодействие, системное тестирование и подобную муть вы решили не упоминать?
- конфигурирование — PHP-DI, .env
- взаимодействие — PHP-DI, FastRoute, может какой Event Dispatcher еще
- системное/модульное тестирование — HttpKernel/PSR7 + phpspec + codeception/phpunit/peridot/etc
А какую модель роутинга вы выбирите?
Я же написал — FastRoute, в плане "модели роутинга" вариантов как бы не сильно много. Это все в любом случае вешается как мидлвэр какой.
А ваше приложение будет поддерживать RESTful API, или только классические GET/POST HTTP запросы с возвратом HTML?
А ваше? Есть например symfony/serializer для простеньких штук, и fractal для вещей посложнее. А так — повторю еще раз — PSR-7, HttpKernel.
А как вы будете решать проблему дублирования кода представления?
Twig — у него пока серьезных конкурентов как бы нет.
А если в приложении планируется рендеринг ответа в виде HTML кода, но будет много JS на странице, как вы это решите?
Я последние три года перешел на схему http api + spa на ангуляре и в большинстве случаев решают этот вопрос так. Ну и да, javascript-а в html-е у меня нет в любом случае. И это вообще к теме фреймворка не привязано.
подставьте любой другой архитектурный вопрос
То что вы описали это не архитектура — а инфраструктура. Архитектура — это то как вы например организуете работу с платежками, или систему скидок прикрутили и т.д. То есть это болше влияет на уровне бизнес логики, а там у меня старый добрый PHP (спасибо доктрине за persistence ignorance)
А давно архитектура приложения = фреймворк? Это ж совершенно разные вещи.
Тогда надо прежде определится, что есть фреймворк. Для меня это не набор инстанциированных классов с разрешенными зависимостями, а для вас?
Архитектура — это то как вы например организуете работу с платежками, или систему скидок прикрутили и т.д. То есть это болше влияет на уровне бизнес логики
Лихо вы архитектуру приложения и бизнес логику "сэквивалентили" ))
По остальным ответам — видите, если есть опыт в сборке фреймворка из кусочков то дело идет быстрее, но это, как я уже говорил ранее, "жульничество", ибо вы уже создали свой фреймворк и его пользуете. Собрать такое (работающее) быстро с первого раза не получится.
Архитектура — это то что дорого менять. Хорошая архитектура — позволяет нам безболезненно менять принятые ранее решения. А фреймворк — это просто куча абстракций и базовая реализация типичных юзкейсов.
Да нет, просто у меня много опыта работы с этими компонентами в контексте Symfony. Ну то есть понятно что человек который первый год пишет на Laravel собрать адекватно свой фреймворк практически невозможно. Но ему еще и не нужно, три стадии обучения и все такое, а он еще напервой.
По остальным ответам — видите, если есть опыт в сборке фреймворка из кусочков то дело идет быстрее
Да нет, просто у меня много опыта работы с этими компонентами в контексте Symfony. Ну то есть понятно что человек который первый год пишет на Laravel собрать адекватно свой фреймворк практически невозможно. Но ему еще и не нужно, три стадии обучения и все такое, а он еще напервой.
Архитектура — это то что дорого менять
Тобишь если мой кусок кода написан наспех и крайне каменно, а его вдруг стало необходимо поменять, да как то очень дорого, то этот кусок стал архитектурой?
Но ему еще и не нужно
А вам нужно? )
то этот кусок стал архитектурой?
Совокупность таких кусочков. Это то как вы построили свое приложение, как здание. если на аналогии переходить. А фреймворк — это каркас, то есть без него никак, но это второтепенная часть приложения.
Тобишь выявление рисков есть архитектура?
Тобишь архитектура это то как вы построили приложение. Плохая архитектура — высокий уровень технического долга. А уже технический долг влияет на риски. Потому стараются выстраивать архитектуру так, что бы уровень технического долга был на приемлимом уровне. А для этого надо выявлять риски, что может поменяться и т.д. Естественно не стоит забывать про yagni но и про protected variations помнить надо.
Тобишь архитектура это то как вы построили приложение
Вот так бы сразу, а то про риски да про "дорого менять" ))
Тобишь архитектура это то как вы построили приложение
А что тогда структура? )) Мы сейчас уедем не в ту степь с вами. Может таки не будем уходить в размышления на тему — инфраструктура, структура и архитектура — и объединим все это в одно понятие?
Если да, то фреймворк (в отличии от библиотеки) дает готовую архитектуру.
Пример
Возьмем ZF2. Этот монстр скроен из кучи пакетов, но в нем так же есть задел на архитектуру будущего приложения через Zend\MVC и Application. Пользоваться этим или превратить ZF2 в библиотеку, решаете вы как разработчик, но фреймворк предлагает архитектуру.
Другой пример
В ходе работы у меня набрался десяток очень удобных для меня пакетов, из которых я уже собрал два разных фреймворка. На каждом из них были написаны различные приложения, но архитектура каждого была определена конкретным фреймворком (для того и было создано два фреймворка, а не один).
Возвращаясь к основному вопросу ветки — для создания фреймворка (набора действующих взаимосвязанно пакетов в рамках установленной архитектры) можно потратить несколько дней (а иногда и недель, в зависимости от сложности проекта), а можно воспользоваться предлагаемой архитектурой других фреймворков.
В них тестируется код, но не архитектура или взаимодействие с другим кодом
Архитектура и взаимодействия в них уже протестированы временем, о чем я писал выше.
Или тот-же FastRoute мешает написать поддержку RESTful API?
Скорее мешает вопрос — а что для этого лучше использовать? Когда вы собираете свой первый фреймворк, этот вопрос часто не дает покоя.
А что это за проблема?
Ну вот предположим вам нужна простая админка для управления данными мобильного приложения. Ничего особенного, десяток сущностей, метр JS оберток для удобного GUI, реляционная база и немного кеша. Все ваши экраны будут делится на 3 основных: таблица сущностей, экран добавления, экран редактирования — и десяток виджетов: список выбора, группа checkbox, группа radio, мультивыбор и т.д. По хорошему, в хорошей архитектуре все это должно быть реализовано ровно 1 раз для всех сущностей, и, если необходимо, переопределено, если для конкретной сущности нужно что то особенное.
Использованием отдельных вьюх/рендера? В чем проблема-то?
Что за отдельная вьюха и рендер позволит легко прикручивать JS к странице? Объясню по другому. У вас есть коллекция элементов, которые отдаются с сервера в виде HTML списка. Этот список уже готов к изучению пользователем, но к нему нужно прикрутить кнопки с JS логикой, позволяющие удалять компоненты из этого списка, добавлять их и сохранять результат (список в form). Нужно как то восстановить JS модель прямо из этого HTML списка средствами самого JS, навешать на нее события и при изменении модели перерендерить список. Естественно при инициализации список не должен перерендерится. На деле я уже объяснил как это сделать, но когда речь о новом фреймворке, опять таки встает вопрос — а как лучше? Что и отнимает уйму времени. О чем я и говорю сейчас )
Когда вы собираете свой первый фреймворк, этот вопрос часто не дает покоя.
Мы тут обсуждали фреймворк на компонентах. Я уже говорил что таким надо заниматься только когда уже есть опыт с одним-двумя фреймворками и отдельно компонентами. Ну то есть это уже уровень чуть повыше должен быть у разработчика.
Давным давно выбрал Yii2 из эстетических соображений и ни разу об этом не пожалел.
Если найду в нем баг, с работью пришлю им pull request и заработаю ещё +1 в карму ))
Если найду в нем баг, с работью пришлю им pull request и заработаю ещё +1 в карму ))
А как насчет Lumen?
Почему указан Symfony 2 когда как актуальная версия 3?
Надо тогда уж просто писать — Symfony.
Ну и конечно, почему нет выбора нескольких позиций?
Symfony 3 / Laravel 5+
Очевидно что для крупных проектов и средних, лучшие решения.
Правда Symfony мало кому по зубам, поэтому выбирают yii.
Надо тогда уж просто писать — Symfony.
Ну и конечно, почему нет выбора нескольких позиций?
Symfony 3 / Laravel 5+
Очевидно что для крупных проектов и средних, лучшие решения.
Правда Symfony мало кому по зубам, поэтому выбирают yii.
Ого!.. Столько минусавания за собственные решения что лучше промолчу. Хорошо что создатели сомфоней и прочих лаваралей в свое время не участвовали в дискусиях на хабре — огребли бы по полной програме сколько в их будущем фреймворке будет костылей, что это будут велосипеды с квадратными колесами и в том же духе.
тем не менее 17% работают без фреймворка.
Полностью поддерживаю. Свой фреймворк это хорошо когда есть composer и хороший опыт хотя бы с тремя популярными и понимание того что делаешь, а вот с последним у многих проблемки.
Тут нет корреляции. Люди просто зачастую не понимают, что они делают. И когда новички начинают писать свои фреймворки «потому что зачем так сложно», обычно понимания это не добавляет и выходит намного хуже для бизнеса.
1. Верю, потому не добавляю его в список фреймворков у которых все хорошо. Это весьма специфичный фреймворк и я не рекомендую его новичкам. Однако сильные ребята которые прекрасно знают что такое хорошо и что такое плохо могут делать интересные штуки на нем.
2. по поводу понимания… в целях обучения — пожалуйста, пишите что хотите, но на коммерческих проектах только проверенные и стабильные решения, особенно если у вас нет за плечами хотя бы 5-ти лет серьезной коммерческой разработки (то есть вы еще не умеете писать тесты а уже считаете себя умнее остальных).
В конце конвов помимо роутеров и шаблонизаторов, вам проект еще надо написать, а это нередко не менее сложная штука и сосредоточиться лучше на этом.
3. новички так или иначе пишут свои фреймворки. Сначала маршрутизацию свою навояют, потом шаблонизатор, потом «класс для работы с базой». Как-то так это происходит в среднем.
4. Полностью согласен. Но они как-то влазят, ибо рынок труда не насыщен.
5. Фреймворки не усложнены. Там не сложно, там много. Серьезно, даже если мы возьмем самый какой-нибудь сложный пакет на PHP — доктрину например, то если разобраться там все компоненты системы не особо сложны. Их просто много. И много их что бы покрыть 95% юзкейсов возникающих у разработчиков. А все это ведет к уменьшению издержек.
p.s.
к вопросу о адекватности. Вы можете просто рассписать тут какими проектами занимаетесь, количество людей в команде, среднюю длительность проектов и уровень их сложности. А далее мы можем уже продолжать конструктивый разговор на тему «нужны фреймворки или можно обходиться библиотеками и забить на загоны по инверсии зависимостей».
2. по поводу понимания… в целях обучения — пожалуйста, пишите что хотите, но на коммерческих проектах только проверенные и стабильные решения, особенно если у вас нет за плечами хотя бы 5-ти лет серьезной коммерческой разработки (то есть вы еще не умеете писать тесты а уже считаете себя умнее остальных).
В конце конвов помимо роутеров и шаблонизаторов, вам проект еще надо написать, а это нередко не менее сложная штука и сосредоточиться лучше на этом.
3. новички так или иначе пишут свои фреймворки. Сначала маршрутизацию свою навояют, потом шаблонизатор, потом «класс для работы с базой». Как-то так это происходит в среднем.
4. Полностью согласен. Но они как-то влазят, ибо рынок труда не насыщен.
5. Фреймворки не усложнены. Там не сложно, там много. Серьезно, даже если мы возьмем самый какой-нибудь сложный пакет на PHP — доктрину например, то если разобраться там все компоненты системы не особо сложны. Их просто много. И много их что бы покрыть 95% юзкейсов возникающих у разработчиков. А все это ведет к уменьшению издержек.
p.s.
к вопросу о адекватности. Вы можете просто рассписать тут какими проектами занимаетесь, количество людей в команде, среднюю длительность проектов и уровень их сложности. А далее мы можем уже продолжать конструктивый разговор на тему «нужны фреймворки или можно обходиться библиотеками и забить на загоны по инверсии зависимостей».
только yii2
Я буду на Phalcon писать, как и раньше, как и год назад)
Параллельно буду делать на Laravel, надо расширяться
Параллельно буду делать на Laravel, надо расширяться
Писать — что?
Конечно в лидерах по такому опросу будут RAD-фреймворки из-за количественного преобладания задач по созданию типовых веб-сайтов.
А если я занимаюсь поддержанием и развитием legacy кода под большой нагрузкой, в котором много backend логики реализовано?
Я лично выбрал Silex.
Конечно в лидерах по такому опросу будут RAD-фреймворки из-за количественного преобладания задач по созданию типовых веб-сайтов.
А если я занимаюсь поддержанием и развитием legacy кода под большой нагрузкой, в котором много backend логики реализовано?
Я лично выбрал Silex.
Запиленые под себя компоненты Symfony.
Когда писал на PHP, пару лет назад, очень понравился Phalcon. Если бы сейчас дали задание реализовать проект на PHP, то я выбрал бы именно Phalcon.
Хотел Symfony2, но там пока непонятные дела с mongodb-odm-doctrine, поддержка ext-mongodb (привет php7) — с помощью php драйвера. Поэтому пока взор упал на Laravel
Выбрал бы конечно Laravel или Phalcon. Да и смотрю Zend выбирают все меньше и меньше, это наверное потому что он суров к стандартам.
Выбирающим Yii: фреймворк абсолютно не известен на западе.
Если вдруг вы захотите вкатиться на Upwork или другие биржи — ваш выбор Laravel
Если вдруг вы захотите вкатиться на Upwork или другие биржи — ваш выбор Laravel
Apple выбирает Symfony. ну это так, накинуть)
Что Laravel, что Symfony — однофигственно. Для относительно опытного разработчика не будет никакой разницы между ними, т.к. они оба слабосвязанные и с одинаковым успехом можно использовать как L5 + Doctrine + Twig, так и Symfony + Eloquent + Blade (ну для примера).
Чего не сказать о Yii, там надо довольно сильно помучаться, что бы выдрать AR из ядра, да и идеи Yii довольно сильно влияют на мышление разработчиков и перейти на Symfony им будет проблематично, надо весь мозг себе перестраивать будет.
P.S. Это я по себе сужу, т.к. использовал немного Yii, перешёл на Laravel и скоро перебираюсь на Symfony, хотя и сейчас уже использую его компоненты вовсю.
Чего не сказать о Yii, там надо довольно сильно помучаться, что бы выдрать AR из ядра, да и идеи Yii довольно сильно влияют на мышление разработчиков и перейти на Symfony им будет проблематично, надо весь мозг себе перестраивать будет.
P.S. Это я по себе сужу, т.к. использовал немного Yii, перешёл на Laravel и скоро перебираюсь на Symfony, хотя и сейчас уже использую его компоненты вовсю.
Забыли старый, добрый Codeigniter. Он кстати готовится к 4 версии на РНР7
CakePHP 3.x
Пока все пишут на том, что представлено в списке голосования, дальновидные люди уже давно пересели на Phalcon и Symfony3.
26% (560) Laravel 5
27% (547) Yii 2
Это как так получилось?
Совпадение? Не думаю!
27% (547) Yii 2
Это как так получилось?
Совпадение? Не думаю!
Phalcon на PHP7, Yii2, чистый PHP.
судя по комментариям и минусоплюсам, тут сидят фанаты всякой фигни.
плюс несовсем понятно обсуждение, почему PHP сам по себе хуже.
плюс несовсем понятно обсуждение, почему PHP сам по себе хуже.
Просвети что нынче не фигня?
В рамках пэхапэ естественно )
В рамках пэхапэ естественно )
Тоже имею интерес узнать, что нынче не фигня.
Для того что бы подобное утверждать, приведите формулировку «что есть фреймворк». А потом задумайтесь, может ли быть так, что фреймворка вообще нет?
фрейморки — это то, за что здесь голосовалось
Вы же понимаете что это определение вообще ничего не объясняет?
Многие путают фреймворки с библиотеками, поэтому такая вырезка:
Многие думают что фреймворк и приложение неотделимые друг от друга понятия. Хотя фреймворк, это строительные леса для приложения.
Было бы странно если бы мы строили дом, а строительные леса и инфраструктура были бы намертво впаены в стены. Случись что с инфраструктурой, например труба лопнула, пришлос бы ломать стены что бы добраться. Обслуживание такого дома будет явно обходиться сильно дороже.
Словом распространенное заблуждение в том, что фреймворк влияет на архитектуру приложения. Это далеко не так. Нормальные фреймворки, вроде Zend, Symfony или Laravel, вообще ничего нам не диктуют. Основные архитектурные ограничения накладываются в отношении UI для нашего приложение, а последнее ничего не должно знать о UI (MVC там, разделение ответственности).
ORM — это уже опциональные штуки. Они далеко не всегда нужны (например если мы используем mongodb — у нас нет связей а стало быть не нужны и ORM). Да и нормальный фреймворк предоставляет возможность выкидывать ненужные компоненты и заменять их своими.
И даже если мы будем делать все на отдельных библиотеках, со временем у нас выростет прослойка между приложением и библиотеками (инверсия зависимостей), и эта прослойка и будет нашим фреймворком.
Нормальные фреймворки, вроде Zend, Symfony или Laravel, вообще ничего нам не диктуют
Не диктуют, но предлагают. Применять их предложения иль нет, дело ваше, и это есть хорошо.
А вот библиотеки ничего не предлагают в принципе, иначе это уже не библиотеки. О том и идет речь, когда говорят что — фреймворк влияет на архитектуру приложения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
На каком фреймворке вы будете писать PHP приложение в 2016 году?