Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 146
А что такого хорошего в Laravel, что за него так голосуют? Видел какие-то статьи о нем, но серьезно не вникал, а тут смотрю, он даже Симфони побил…
Маркетинг точно хорош по-ходу
Нет у них маркетинга. Просто нашли неплохой баланс по разным критериям и успешно заняли освобождающуюся нишу yii, пока тот возился с разработкой второй версии.
Есть там маркетинг и он прекрасен. Стиль его как у RoR в его лучшие годы. Но и да, сам фреймворк неплох. Иначе даже с отличным маркетингом было бы плохо.
Это сейчас у них уже есть какой-то маркетинг. А раньше ничего не было, и рост пользовательской базы был скорее вирусным
Да ну? В том же Nettuts еженедельно писали статьи исключительно про Laravel
И это было года 2 назад (ещё до выхода L4)
И это было года 2 назад (ещё до выхода L4)
Потому что у них редактор Jeffrey Way? :) А сейчас он считай второй человек в laravel после Тейлора.
Я уж не знаю, как они взаимодействовали между собой в то время и на каких условиях.
Я уж не знаю, как они взаимодействовали между собой в то время и на каких условиях.
Был редактором ) Сейчас Джефри скорее евангелист, но не контрибьютор проекта. В команде Laravel сейчас 4 человека, но фигачит всё равно исключительно Тейлор github.com/laravel/framework/commits/5.0
И чем вам это не маркетинг? Чувак пиарил свое детище как мог. И у него это получалось делать.
Кто пиарил? Вы знаете на каких условиях Джефри пиарил фреймворк Тейлора?
И маркетинг это еще не всё: ту же Aura пиарят как могут, но без поддержки пользователей она мало кому нужна
И маркетинг это еще не всё: ту же Aura пиарят как могут, но без поддержки пользователей она мало кому нужна
У Ауры большие проблемы с подачей информации, да и целевая аудитория другая. Да и не видел я никакого активного продвижения в комьюнити PHP, только упоминания в контексте каких-либо сравнений.
Laravel хорошо «продается» среди хипстеров и молодежи, у него все ок с документацией и информативностью. Весь сабрэддит php загадили ссылками в свое время. Для маленьких и средних проектов он норм. Aura нацелена все же на проекты побольше и она сложнее для входа.
Laravel хорошо «продается» среди хипстеров и молодежи, у него все ок с документацией и информативностью. Весь сабрэддит php загадили ссылками в свое время. Для маленьких и средних проектов он норм. Aura нацелена все же на проекты побольше и она сложнее для входа.
Не знаю что там с маркетингами, но мне, как человеку никогда не писавшему на PHP, этот фреймворк показался очень понятным и простым.
Так почитайте про него хотя-бы документацию официальную в переводе на русский) Быть может, поймёте, почему он так популярен) laravel.su/docs/5.0/installation
Спасибо что не погуглить послали…
Раз уж пишете комментарий, то скажите уж что-нибудь полезное, а не просто язвите. Может, контр-аргумент какой против использования реально удобного инструмента для веб-разработки, который перенял и развил лучшее, что есть в Ruby и RoR.
Я пишу сейчас параллельно один проект на руби, один — на Ларавеле. Даже не знаю, на каком из них мне приятнее работать, если честно)
Я пишу сейчас параллельно один проект на руби, один — на Ларавеле. Даже не знаю, на каком из них мне приятнее работать, если честно)
А как фреймворк мог перенять и развить что-то из другого языка программирования.
P.s. фразы типа «я сейчас пишу один проект на пайтоне, один на бусте» нереально доставляют.
P.s. фразы типа «я сейчас пишу один проект на пайтоне, один на бусте» нереально доставляют.
Вот пример комментария, который показывал преимущества postgre на mysql, после чего я реально начал читать документацию, потому что фичи, на которые указали были интересными: habrahabr.ru/post/246339/#comment_8187275
А ваш комментарий никакой ценности не несет. «Иди читай документацию» это один из любимых ответов на русскоязычных форумах программистов, из-за которого так много народу переключилась на форумы англоязычные.
А ваш комментарий никакой ценности не несет. «Иди читай документацию» это один из любимых ответов на русскоязычных форумах программистов, из-за которого так много народу переключилась на форумы англоязычные.
Вас расстроит если я скажу что мне не нравятся ни RoR ни Laravel?
Постараюсь ответить сразу всем. Esc, вам так трудно пробежаться по документации к инструменту? Она простая и приятная для восприятия, и моё сообщение — это не аналог типичной сисадминской фразы «иди читай маны». Там читать-то нечего: можно пробежаться по ней за 10 минут и уже сделать выводы.
Fesor, почему это может меня расстроить?) Есть много других прекрасных инструментов. Но и Ларавел с Руби свою нишу ведь заняли не только из-за хорошего маркетинга)
murzilka, там очень многое было перенято из хороших и верных идей и подходов к разработке. По сути, если ты умеешь писать на Ларавеле, значит тебе будет очень просто начать писать на RoR, так как практически всё там будет для тебя очень знакомо.
Fesor, почему это может меня расстроить?) Есть много других прекрасных инструментов. Но и Ларавел с Руби свою нишу ведь заняли не только из-за хорошего маркетинга)
murzilka, там очень многое было перенято из хороших и верных идей и подходов к разработке. По сути, если ты умеешь писать на Ларавеле, значит тебе будет очень просто начать писать на RoR, так как практически всё там будет для тебя очень знакомо.
Что именно? Хотя бы 5 конкретных примеров.
Чего общего между Ларавелем и Ruby in Rails:
— Общее стремление к простому и чистому коду. Авторы руби вообще помешаны на этом, даже чересчур, на мой личный взгляд: они придумали для своего языка целый вагон синтаксического сахара, и конечно же свой Ruby On Rails они постарались тоже сделать простым и логичным. Авторы Laravel в целом стремятся достичь той же цели: приблизить код приложений к простому и чистому виду с мягко связанными между собой компонентами. И это им в целом действительно вполне удаётся, на мой взгляд.
— Очень схожие друг с другом структура каталогов приложения, файлов конфигурации, миграций и seed-данных.
— Механизм миграций БД и компонент создания таблиц и связей между ними. И использование миграций изначально считается правильным подходом, причём Ларавел даже сразу заботливо создаёт для вас две миграции для создания таблицы пользователей и таблицы восстановления паролей. Также, он изначально создаёт готовые контроллеры и view-шаблоны для данных функций. Вы можете использовать всё это сразу в своём приложении вообще без доработок, но также можете и изменить миграции и функционал под свои личные нужды. В Руби за это отвечает gem Devise, он очень похож по функциям и предоставляет даже большее количество интересных и готовых к использованию фич, но вот дорабатывать его под свои нужды оказывается гораздо сложнее, чем заготовку от авторов Laravel.
— Работа ORM в Ларавел организована практически также, как в Руби. Например, из рельсов там взяты такие вещи, как Query Scopes, ну и в целом синтаксис работы с ORM практически идентичен этому же синтаксису в RoR.
— Возможность мягкого удаления объектов из БД через специальную колонку-таймстамп deleted_at, изначально равную null. Это позволяет удалять объекты без их реального физического удаления из базы. Опять же, данная идея взята из рельсов.
— Middleware, промежуточный слой в приложении, в котором производятся различные проверки (на авторизацию, например), логгирование, защита от CSRF, добавляются какие-то заголовки к ответам, и так далее. Всё это также есть и в рельсах.
— Механизм описания правил роутинга. Очевидно, что разрабатывался он на основе того, как это реализовано в RoR.
— Маленькие функции-хелперы для удобной разработки. Их очень много в рельсах, Ларавел также использует определённое их количество. Я также большой любитель подобных маленьких функций, так как вместе с ними код становится короче и приятнее для восприятия, и я даже сам создал для себя небольшое количество своих функций, которые использую в разработке.
— Использование разных сервисных команд для управления приложением через командную строку, а также генерация готового кода (скаффолдинг). Это тоже по большей части перенято из рельсов, и зачастую это действительно удобно использовать.
Это из тех сходств, которые я сейчас смог вспомнить. Что касается того, в чём Ларавел обошёл Руби, это такие вещи, как:
— Контракты, благодаря которым осуществляется мягкое связывание различных компонентов системы между собой, а также благодаря ним упрощается разработка и отладка приложения. В этом плане рельсы очень сильно отстают от Ларавел, так как в них подобных вещей просто не существует. Это кстати вообще довольно выделяющая Laravel среди других фреймворков фича, её, кажется, в данный момент нет вообще ни у кого другого, и пользу от использования контрактов, я думаю, мы увидим только спустя несколько лет жизни мира программирования, когда разработчики начнут писать свои компоненты в соответствии с контрактами, принятыми в сообществах.
— Laravel 5 работает на основе стандарта PSR-4. Это также то достоинство, которым может похвастаться только Laravel среди всех PHP-фреймворков. И в Руби такого я не видел. И это также то прекрасное нововведение, которое позволяет навести порядок в коде. Теперь, у всего вашего личного кода, написанного для конкретного из сайтов, есть своё пространство имён, и все остальные компоненты этого мира, которые писали другим разработчики, работают в своих собственных пространствах имён и никак не смешиваются друг с другом. Вы можете называть все свои классы так, как хотите, и это никак не повлияет на работу вашего приложения.
— Возможность написать весь сайт абсолютно не используя контроллеры, просто описав весь его код с помощью анонимных функций прямо в routes.php. Такого, кстати, по-моему, также нет нигде, кроме как в Laravel. Для маленьких и простых сайтов, а также для обучения новичков разработке, такой вариант оказался очень даже кстати.
— Вообще, сравнивая Laravel и Ruby On Rails, я всё-таки некорректно выразился, сказав, что авторы Laravel переняли и развили всё, что есть в Рельсах. Нет, на самом деле в Рельсах есть еще множество других интересных вещей, которых я не увидел в Laravel, и которые мне понравились. Также мне следует признать, что я начал изучить Ruby и RoR совсем недавно и в данный момент не могу дать всеобъемлющего сравнения между этими двумя инструментами. Я лишь написал те вещи, которые я увидел в самое первое время ознакомления с руби и рельсами. Думаю, спустя пол года-год, у меня уже сформируется более детальное мнение на данную тему. А пока что — вот, то сложилось что из моих личных знаний и наблюдений.
— Общее стремление к простому и чистому коду. Авторы руби вообще помешаны на этом, даже чересчур, на мой личный взгляд: они придумали для своего языка целый вагон синтаксического сахара, и конечно же свой Ruby On Rails они постарались тоже сделать простым и логичным. Авторы Laravel в целом стремятся достичь той же цели: приблизить код приложений к простому и чистому виду с мягко связанными между собой компонентами. И это им в целом действительно вполне удаётся, на мой взгляд.
— Очень схожие друг с другом структура каталогов приложения, файлов конфигурации, миграций и seed-данных.
— Механизм миграций БД и компонент создания таблиц и связей между ними. И использование миграций изначально считается правильным подходом, причём Ларавел даже сразу заботливо создаёт для вас две миграции для создания таблицы пользователей и таблицы восстановления паролей. Также, он изначально создаёт готовые контроллеры и view-шаблоны для данных функций. Вы можете использовать всё это сразу в своём приложении вообще без доработок, но также можете и изменить миграции и функционал под свои личные нужды. В Руби за это отвечает gem Devise, он очень похож по функциям и предоставляет даже большее количество интересных и готовых к использованию фич, но вот дорабатывать его под свои нужды оказывается гораздо сложнее, чем заготовку от авторов Laravel.
— Работа ORM в Ларавел организована практически также, как в Руби. Например, из рельсов там взяты такие вещи, как Query Scopes, ну и в целом синтаксис работы с ORM практически идентичен этому же синтаксису в RoR.
— Возможность мягкого удаления объектов из БД через специальную колонку-таймстамп deleted_at, изначально равную null. Это позволяет удалять объекты без их реального физического удаления из базы. Опять же, данная идея взята из рельсов.
— Middleware, промежуточный слой в приложении, в котором производятся различные проверки (на авторизацию, например), логгирование, защита от CSRF, добавляются какие-то заголовки к ответам, и так далее. Всё это также есть и в рельсах.
— Механизм описания правил роутинга. Очевидно, что разрабатывался он на основе того, как это реализовано в RoR.
— Маленькие функции-хелперы для удобной разработки. Их очень много в рельсах, Ларавел также использует определённое их количество. Я также большой любитель подобных маленьких функций, так как вместе с ними код становится короче и приятнее для восприятия, и я даже сам создал для себя небольшое количество своих функций, которые использую в разработке.
— Использование разных сервисных команд для управления приложением через командную строку, а также генерация готового кода (скаффолдинг). Это тоже по большей части перенято из рельсов, и зачастую это действительно удобно использовать.
Это из тех сходств, которые я сейчас смог вспомнить. Что касается того, в чём Ларавел обошёл Руби, это такие вещи, как:
— Контракты, благодаря которым осуществляется мягкое связывание различных компонентов системы между собой, а также благодаря ним упрощается разработка и отладка приложения. В этом плане рельсы очень сильно отстают от Ларавел, так как в них подобных вещей просто не существует. Это кстати вообще довольно выделяющая Laravel среди других фреймворков фича, её, кажется, в данный момент нет вообще ни у кого другого, и пользу от использования контрактов, я думаю, мы увидим только спустя несколько лет жизни мира программирования, когда разработчики начнут писать свои компоненты в соответствии с контрактами, принятыми в сообществах.
— Laravel 5 работает на основе стандарта PSR-4. Это также то достоинство, которым может похвастаться только Laravel среди всех PHP-фреймворков. И в Руби такого я не видел. И это также то прекрасное нововведение, которое позволяет навести порядок в коде. Теперь, у всего вашего личного кода, написанного для конкретного из сайтов, есть своё пространство имён, и все остальные компоненты этого мира, которые писали другим разработчики, работают в своих собственных пространствах имён и никак не смешиваются друг с другом. Вы можете называть все свои классы так, как хотите, и это никак не повлияет на работу вашего приложения.
— Возможность написать весь сайт абсолютно не используя контроллеры, просто описав весь его код с помощью анонимных функций прямо в routes.php. Такого, кстати, по-моему, также нет нигде, кроме как в Laravel. Для маленьких и простых сайтов, а также для обучения новичков разработке, такой вариант оказался очень даже кстати.
— Вообще, сравнивая Laravel и Ruby On Rails, я всё-таки некорректно выразился, сказав, что авторы Laravel переняли и развили всё, что есть в Рельсах. Нет, на самом деле в Рельсах есть еще множество других интересных вещей, которых я не увидел в Laravel, и которые мне понравились. Также мне следует признать, что я начал изучить Ruby и RoR совсем недавно и в данный момент не могу дать всеобъемлющего сравнения между этими двумя инструментами. Я лишь написал те вещи, которые я увидел в самое первое время ознакомления с руби и рельсами. Думаю, спустя пол года-год, у меня уже сформируется более детальное мнение на данную тему. А пока что — вот, то сложилось что из моих личных знаний и наблюдений.
Возможность написать весь сайт абсолютно не используя контроллеры, просто описав весь его код с помощью анонимных функций прямо в routes.php. Такого, кстати, по-моему, также нет нигде, кроме как в Laravel
What? Тот же slim целиком вокруг этой идеи построен
Вы так пишете, как-будто это что-то удивительное, что я в чём-то оказался не прав. Я ведь написал: «по-моему». И я говорил о полноценных фреймворках. Slim — это же микрофреймворк, на котором только анонимными функциями всё и пишется.
В любом фреймворке можно написать весь сайт абсолютно не используя контроллеры, и сам фреймворк кстати тоже, но я бы это не относил к достоинствам, т.к. если вам уж так понадобилось что-то из фреймворка то лучше пусть это будет как бандлы в симфони, чтобы не тянуть весь фреймворк.
Кстати как у laravel с дополнительными модулями, есть ли столько чтобы можно было написать минимум кода и получить сайт для блога?
Кстати как у laravel с дополнительными модулями, есть ли столько чтобы можно было написать минимум кода и получить сайт для блога?
Дополнительные модули можно поискать здесь: packalyst.com
Их там довольно много всяких разных, хотя я лично редко пользуюсь сторонними модулями, предпочитая потратить немного времени на написание своего решения) Ну и я не блогами обычно занимаюсь, а чем-то более специфичным. Единственный модуль, который я пока ставил вместе с основным фреймворком — это laravel-breadcrumbs для удобного создания хлебных крошек на сайте. Плюс, у ларавела довольно неплохо с основным функционалом, который он предлагает из коробки. Там почти всё что нужно уже собрано, остаётся только поизучать документацию.
Их там довольно много всяких разных, хотя я лично редко пользуюсь сторонними модулями, предпочитая потратить немного времени на написание своего решения) Ну и я не блогами обычно занимаюсь, а чем-то более специфичным. Единственный модуль, который я пока ставил вместе с основным фреймворком — это laravel-breadcrumbs для удобного создания хлебных крошек на сайте. Плюс, у ларавела довольно неплохо с основным функционалом, который он предлагает из коробки. Там почти всё что нужно уже собрано, остаётся только поизучать документацию.
Единственное что огорчает, это ад в разборе стека вызовов — неинформативность вывода ошибок.
По стеку вызовов тяжело определить, что именно произошло и что с этим делать.
Я бы назвал это адом отладки.
А так же разработчики Laravel 5 стал страдать перфекционизмом — доводя многие привычные вещи к абсурдному состоянию.
ЗЫ.
CSRF по умолчанию для всех POST запросов, а как же AJAX.
Model — куда делись модели и как их подключить, почти весь форум забит :)
По стеку вызовов тяжело определить, что именно произошло и что с этим делать.
Я бы назвал это адом отладки.
А так же разработчики Laravel 5 стал страдать перфекционизмом — доводя многие привычные вещи к абсурдному состоянию.
ЗЫ.
CSRF по умолчанию для всех POST запросов, а как же AJAX.
Model — куда делись модели и как их подключить, почти весь форум забит :)
Ну не такой уж ад) обычный стектрейс, по-моему.
Аякс-запросы тоже защищаются дополнительным заголовком, смотрим документацию: laravel.com/docs/5.0/routing#csrf-protection, раздел «X-CSRF-TOKEN».
Насчёт моделей — действительно странное и какое-то абсурдное решение. Но решается легко — создаём папку Models и создаём все свои модели в ней)
Аякс-запросы тоже защищаются дополнительным заголовком, смотрим документацию: laravel.com/docs/5.0/routing#csrf-protection, раздел «X-CSRF-TOKEN».
Насчёт моделей — действительно странное и какое-то абсурдное решение. Но решается легко — создаём папку Models и создаём все свои модели в ней)
Да нет, стектрейс то необычный.
Это тот вид стректрейса который говорит — полезь в ядро и разбери мои внутренности и тогда поймешь, что я имел ввиду :)
А я такой: :-o =O
А он мне X-CSRF-TOKEN — не нужен в некоторых AJAX запросах, а вот в формах необходим и начинаю писать велосипед, вот здесь он должен работать, а вот здесь нет — это просто неудобно.
А на счет, моделей, да там еще надо конфиг править по автозагрузке, но нигде в документации об этом не описано.
ЗЫ.
Документация сыровата, приходится лазить на Laracast и StackOverflow.
Это тот вид стректрейса который говорит — полезь в ядро и разбери мои внутренности и тогда поймешь, что я имел ввиду :)
А я такой: :-o =O
А он мне X-CSRF-TOKEN — не нужен в некоторых AJAX запросах, а вот в формах необходим и начинаю писать велосипед, вот здесь он должен работать, а вот здесь нет — это просто неудобно.
А на счет, моделей, да там еще надо конфиг править по автозагрузке, но нигде в документации об этом не описано.
ЗЫ.
Документация сыровата, приходится лазить на Laracast и StackOverflow.
yii2 вы судя по всему не видели. В вашем комменте можете поменять laravel на yii2 и текст будет на 80% верен.
(yii2 тоже psr-4)
(yii2 тоже psr-4)
Потому что это фреймфорк для людей. Вот вам простой пример stackoverflow.com/a/28370628/1331425 и таких примеров, где «Laravel takes care of the rest» достаточно много в повседневной работе.
Кроме того, количество написанный строк кода для того чтобы написать тоже самое в сравнении с symfony2 меньше примерно на 20%, что значительно сказывается на читабельности.
Кроме того, количество написанный строк кода для того чтобы написать тоже самое в сравнении с symfony2 меньше примерно на 20%, что значительно сказывается на читабельности.
Прошу прощения за опечатки, все реже печатаю на русском.
Вы минимум нолик потеряли в процентах, быть разница всего 20%, то symfony был бы лидером, а так ну очень уж большой оверхед для подавляющего большинства веб проектов.
У меня скептическое отношение к Ларавелу, а в последнее время оно усилилось из-за подобных ситуаций — почитайте вот эту ссылочку www.reddit.com/r/PHP/comments/3041i6/moving_the_location_of_some_storage_files_breaks/
Тейлор может совершенно спокойно сломать минорный релиз, потом говорить, что это он «ненарошно, хотя всё указывает, что изменение было спланировано под его коммерческий продукт — envoyer. Так что я даже не знаю для каких он людей, и можно ли написать на нем что-то большее чем блог+магазин.
Тейлор может совершенно спокойно сломать минорный релиз, потом говорить, что это он «ненарошно, хотя всё указывает, что изменение было спланировано под его коммерческий продукт — envoyer. Так что я даже не знаю для каких он людей, и можно ли написать на нем что-то большее чем блог+магазин.
Полностью поддерживаю. На мой взгляд, L4 развивалась так, чтобы всем было удобно. А вот L5 уже развивается так, как удобно в первую очередь Тейлору. Поэтому несмотря на все прелести L5, я не вижу явных преимуществ перед тем же L4 и переходить на новую версию пока не планирую. Хотя возможно, мое мнение со временем изменится…
P.S. Для чистоты эксперимента стоило бы проводить опрос в стиле: L3, L4, L5, Yii, Yii2. Ну, либо: Laravel (L3+L4+L5), Yii (Yii + Yii 2)
P.S. Для чистоты эксперимента стоило бы проводить опрос в стиле: L3, L4, L5, Yii, Yii2. Ну, либо: Laravel (L3+L4+L5), Yii (Yii + Yii 2)
Увы, переходить нужно всегда, продукт развивается, чинятся баги и что важно проблемы безопасности. Опять таки, исходя из политики Тейлора — он поддерживает только одну версию, потому оставаясь на L4 вы скорее всего лишаете себя дальнейших обновлений. Имхо, такая политика обновлений недопустима, особенно для фреймворка претендующего на лидерство в РНР мире.
Для серьезных проектов есть Symfony с четким графиком релизов и long-term support релизами. На счет наличия последнего у Zend не уверен. А Laravel как по мне набор велосипедов, хоть и грамотных местами. Скажем тамошняя реализация IoC намного лучше той что есть в Symfony из коробки.
Угу. Кроме того, уж больно быстро они бросают поддерживать свои предыдущие версии.
Непонятно, как был поставлен вопрос в опросе: что вы считаете нужным использовать или что реально используете? Подозреваю, что первое.
Потому как ну очень странно выглядит такое подавляющее лидерство Ларавеля — при всех его достоинствах, он молод и вряд ли бы смог так быстро подвинуть все многолетние наработки.
Потому как ну очень странно выглядит такое подавляющее лидерство Ларавеля — при всех его достоинствах, он молод и вряд ли бы смог так быстро подвинуть все многолетние наработки.
Не знаю как там Ларавел, а вот за то что PHPixie стала так популярна я безумно рад =)
Я до сих пор считал что это очередной no-name фреймворк к слову. И от того недоумение почему PHPixie стал самым самым, не смотря на то что по вакансиям всем нужна Symfony2 и Laravel…
Подозреваю, что jigpuzzled приложил руку к тому, чтобы фреймворк оказался не на последнем месте в опросе ;)
Ну я конечно твитил и постил налево и направо чтоб народ голосовал, но и сам очень удивлен что столько людей набралось, хотя с доугой стороны ~400 человек не так уж много
0.о ~ 400 это много для РНР проекта. В моем понимании. Если бы эти 400 человек ещё б звездочку на гитхабе поставили, вообще было б замечательно. Плюс, я так понимаю, получившийся результат сможет существенно привлечь внимание к Pixie ) Так что поздравляю!
Это дофига. У нас в Facebook-группе 25600 участников и мы там закрепляли пост. Голосов насчитали только 450.
Ну как сказать молод… Процентов 60 — symfony, ещё процентов 25 — всякие популярные библиотечки, осталось всё это связать в одну архитектуру приложения и вуаля, Laravel готов ;)
Он основан на многолетних наработках. Да и хипстеров хватает.
Можно ли было как-то автоматически исследовать, что используется, например, в топ-1000 сайтов? Например, по наличию каких-то характерных файлов на сервере, может, по оформлению кода и каким-нибудь другим признакам? (PHP не использую, потому — спрашиваю)
Нет, это же не CMS. Тут нет никаких шаблонных пресетов, все роуты зависят от программистов. А исходный код получить нет возможности.
На самом деле многие фреймворки можно определить, если немного покопать. Например по ответам js-валидации, подключаемым js-либам, входящим в ядро фреймворка, способу именования ассетов/сборок ассетов, роуту к капче, самой капче и тд. Можно попробовать сгенерировать запрос таким образом, чтобы попасть на экшен обработчик ошибок и понять по нему.
Судя по всему вы не использовали фрейморки. Там нет никаких стандартных js библиотек, нет никакой js валидации, нет определённого именования ассетов (разве что можно rails определить по их asset pipeline, да и то, у laravel есть точно такой же), роутинг к каптчам тоже произвольный и прочее. Единственное — лару зачастую можно определить по имени сессии, но и это меняется одной строкой в конфигах (правда мало кто это делает).
Использовал yii/yii2, ларавел, симфони, симфони2, зенд и фалкон (это не потому что я такой многостаночник, на фрилансе разное бывает). Почти каждый из них определю, если разработчики не переопределяли поведение ключевых компонентов и используют минимальный набор компонентов ядра фреймворков по которому можно определить.
ps навешивать ярлыки некомпетентости не разбираясь в вопросе это верх некомпетентности.
ps навешивать ярлыки некомпетентости не разбираясь в вопросе это верх некомпетентности.
Не, ну обожаю когда минусят, а на предложение оспорить (чуть выше) — тишина. Если я заблуждаюсь — был бы рад узнать что-то новое, где именно я ошибся в выводах. Благодарю.
На таком говне как пхп не может быть нормальных фреймворков.
Почему верхний коммент в ветке (кстати высказанное вслух мнение) в минусах — довольно очевидно, но вот почему это г… но от ivaaaan тоже кстати донельзя аргументированное (но притом откровенное оскорбление кстати) в плюсе, я не понимаю. Вот не понимаю и все…
Достаточно же просто поставить zenden2k, минус, зачем же поддерживать оскорбления.
Достаточно же просто поставить zenden2k, минус, зачем же поддерживать оскорбления.
PHP-фактор же.
Оба человека не аргументировали свои категоричные мнения. Но минусов получит больше тот, кто в посте про PHP решил сказать, что PHP не соответствует его личному восприятию языка как хорошего инструмента. Для многих людей оскорбление их инструмента для заработка воспринимается как личное оскорбление.
Просто попробуйте тоже самое сделать в посте про Ruby/Java — будет тот же результат. Хотя лично меня ничуть не напрягает когда кто-то говорит, что Java не ок. Не вижу смысла поджигать собственные штаны из-за чьего-то личного мнения.
Оба человека не аргументировали свои категоричные мнения. Но минусов получит больше тот, кто в посте про PHP решил сказать, что PHP не соответствует его личному восприятию языка как хорошего инструмента. Для многих людей оскорбление их инструмента для заработка воспринимается как личное оскорбление.
Просто попробуйте тоже самое сделать в посте про Ruby/Java — будет тот же результат. Хотя лично меня ничуть не напрягает когда кто-то говорит, что Java не ок. Не вижу смысла поджигать собственные штаны из-за чьего-то личного мнения.
У него же в публикациях:
Я работаю веб-программистом, пишу на PHP и использую фреймворк Kohana. Для разработки использую потрясающую, на мой взгляд, среду PhpStorm.
Мдаа… Разочаровался? :)
Я работаю веб-программистом, пишу на PHP и использую фреймворк Kohana. Для разработки использую потрясающую, на мой взгляд, среду PhpStorm.
Мдаа… Разочаровался? :)
По логике наоборот, чем хуже язык, тем большее значение имеет фреймворк. И объективно говно или нет решает рынок. На данный момент он решил что пыха это подходящий для большинства задач доступный инструмент.
Деу Нексиа тоже может говно по сравнению с Феррари 458, но для извоза (такси), как инструмент зарабатывания денег, подходит на много лучше.
Деу Нексиа тоже может говно по сравнению с Феррари 458, но для извоза (такси), как инструмент зарабатывания денег, подходит на много лучше.
Тот самый грустный момент, когда работаешь с 1С-Битрикс:(
Ушел плакать
Ушел плакать
битрикс фреймворк — это звучит гордо монетами
Ну так зачем это терпеть? :)
Хватит это терпеть!
фирма, в которой работаю, нравится в целом, так что получается некое балансирование на канате. Над бассейном с крокодилами…
А выбора особого и нет, кому нужен студент-первокурсник, который работать будет 20-25 часов в неделю?) Было бы хотя б знаний и опыта побольше, я б вообще в сторону PHP не смотрел (ну не нравится он мне).
А выбора особого и нет, кому нужен студент-первокурсник, который работать будет 20-25 часов в неделю?) Было бы хотя б знаний и опыта побольше, я б вообще в сторону PHP не смотрел (ну не нравится он мне).
Также PHPixie стал самым популярным фреймворком в возрастной групе до 18 лет.
Я думаю все дело в милой волшебной фее ;)
И в автомагии!
Из за этой феи в сторону jigpuzzled и фреймворка, насколько помню, неоднократно прилетали обвинения в сексизме :)
Такое уверенное лидерство Laravel вызывает только недоумение. Даже об экзотическом Phalcon знаю. А об Laravel даже не слышал, не то чтобы работать с ним.
Проекту нет и 4 лет, а он уже выигрывает у всех существующих. Надо хоть посмотреть что это.
Проекту нет и 4 лет, а он уже выигрывает у всех существующих. Надо хоть посмотреть что это.
А с каких пор Drupal стал фрамеворком?
Наверное с тех пор, как начал состоять из симфони.
изначально. Но заточен только для Drupal :)
Но он при этом достаточно тяжёлый. Встроенное кеширование работает с какой-то свей магией. Базу данных Друпал забивает тоже неплохо. В одном проекте ещё без контента, просто с плагинами и каркасом сайта — в базе данных уже чего-то лежало на 35 мб(!). Я не представляю как разрастётся база, если будет много контента.
В принципе ожидаемо.
Правда я думал (мб. надеялся) что Symfony все же займет первую строчку.
Правда я думал (мб. надеялся) что Symfony все же займет первую строчку.
Результаты правильно писать так — среди пользователей sitepoint.com наибольшей популярностью пользуется Laravel. А сами результаты лучше воспринимать в сравнении с прошлогодними результатами:
Lavavel -4.6%
Symfony +3%
Phalcon -14%
Более 90% голосов за фреймворк Nette отдали разработчики из Чехии
Для голосовавших из России (237):
Yii 2 — 53 (22%)
Yii 1 — 39 (16.5%)
Symfony — 39 (16.5%)
Laravel — 27 (11%)
3 человека из опроса признались, что используют Bitrix (2 из России и 1 из Украины)
Drupal так мало потому что такого варианта не было в выборе и люди дописывали его руками.
Lavavel -4.6%
Symfony +3%
Phalcon -14%
Более 90% голосов за фреймворк Nette отдали разработчики из Чехии
Для голосовавших из России (237):
Yii 2 — 53 (22%)
Yii 1 — 39 (16.5%)
Symfony — 39 (16.5%)
Laravel — 27 (11%)
3 человека из опроса признались, что используют Bitrix (2 из России и 1 из Украины)
Drupal так мало потому что такого варианта не было в выборе и люди дописывали его руками.
Вот замечаю что все эти опросы довольно далеки от реальности. Если посмотреть на вакансии и фриланс проекты (и не только на основных биржах, и крупных баз вакансий, а еще проглядеть региональные аналогичные сервисы), то почему-то встречается куда более понятный набор — битриксы, коханы, CI, yii и похожее. Никаких там ларавелов и в помине нет.
Я думаю просто потому что база старых проектов еще очень велика, и менять в них базу, просто потому что появился новый модный фреймворк никто не будет.
Я думаю просто потому что база старых проектов еще очень велика, и менять в них базу, просто потому что появился новый модный фреймворк никто не будет.
Мое сугубо имхо, определенное похождениями по собеседованиям в феврале (Москва):
1. Битрикс
2. Yii1
3. Symfony
1. Битрикс
2. Yii1
3. Symfony
Я считаю, что Laravel это такое мягкое введение в Symfony.
Тот же Silex не может сравниться в гибкости с Laravel (субъективное ощущение).
Если вам не хватает возможностей Laravel — подключите через composer любую библиотеку Symfony и вы сразу же получите все ее плюшки(И не только Symfony, вы можете подтянуть все что есть на packagist.com)
PS.
Фактически composer autoloader становится дефакто стандартом загрузки библиотек для PHP.
Тот же Silex не может сравниться в гибкости с Laravel (субъективное ощущение).
Если вам не хватает возможностей Laravel — подключите через composer любую библиотеку Symfony и вы сразу же получите все ее плюшки(И не только Symfony, вы можете подтянуть все что есть на packagist.com)
PS.
Фактически composer autoloader становится дефакто стандартом загрузки библиотек для PHP.
Необычно. Опрос на хабре 2011 года.
habrahabr.ru/post/116030/
29% не использую
25% самописный (по сути тоже не использую, т.к. выходит это просто некие удобности для быстрой разработки)
Это на самом деле так за 3 года рынок изменился и я застрял где то в 2011 (я не пишу на фреймворках), или же дело в месте опроса (на том сайте популярно программирование на фреймворках)
habrahabr.ru/post/116030/
29% не использую
25% самописный (по сути тоже не использую, т.к. выходит это просто некие удобности для быстрой разработки)
Это на самом деле так за 3 года рынок изменился и я застрял где то в 2011 (я не пишу на фреймворках), или же дело в месте опроса (на том сайте популярно программирование на фреймворках)
А вот интереса ради, почему вы решили работать без фреймворков? Ну и что вы используете в противном случае?
Ну а так да, с 2011-ого года много чего поменялось в PHP комьюнити. Я даже не побоюсь сказать что за последние лет 5 отчетливо видно что среди PHP разработчиков начала формироваться и перениматься из других языков культура разработки, а велосипедостроение пошло на спад. Слава composer-у и PSR.
Ну а так да, с 2011-ого года много чего поменялось в PHP комьюнити. Я даже не побоюсь сказать что за последние лет 5 отчетливо видно что среди PHP разработчиков начала формироваться и перениматься из других языков культура разработки, а велосипедостроение пошло на спад. Слава composer-у и PSR.
Честно скажу — не пробовал работать с фреймворками. Возможно если я увижу какую нибудь статью вроде реальных примеров кода, как без фреймворка и как с ним и я реально увижу что это куда проще то да, буду использовать. Тут скорее дело в том, что набор моих собственных функций и библиотек уже сам по себе похож на фреймворк. Т.е. там где мне казалось можно как то упростить — я создавал фунции и классы.
Ясно… вы видимо никогда не работали с легаси проектами разработчиков, которые исповедовали ту же веру что и вы. Мол «зачем мне все это если я это и сам написать могу?». И в итоге сидишь ты такой и разбираешься в этом чуде архитектуры, где все на статике и наследовании… и никакой документации…
Ну… и без фреймворка можно норм писать. Берешь себе HttpKernel, берешь PHP DI, доктрину и можно писать неплохие проекты. А вот когда все самостоятельно реализовано, даже банально PSR не используется, это уже боль. И поддерживать это все ад. Вы видимо никогда не сидели на легаси проекте доставшимся от уже уволившихся сотрудников, написанный на самопальных фреймворках.
Вообще все от задач зависит.
как без фреймворка и как с ним
Ну… и без фреймворка можно норм писать. Берешь себе HttpKernel, берешь PHP DI, доктрину и можно писать неплохие проекты. А вот когда все самостоятельно реализовано, даже банально PSR не используется, это уже боль. И поддерживать это все ад. Вы видимо никогда не сидели на легаси проекте доставшимся от уже уволившихся сотрудников, написанный на самопальных фреймворках.
Вообще все от задач зависит.
В общем то понял о чем вы, фреймворк позволяет стандартизировать разработку проекта, чтобы кто либо другой смог с этим работать.
К слову на самом деле от задач сильно зависит, бывает наоборот задача написать такой код, чтобы в случае если кто то другой его получит — он мало что мог бы с ним сделать.
С другой стороны, если структура проекта не сложная, и если написать хорошую документацию то вполне возможно в некоторых случаях этот вариант будет лучше стандартных фреймворков.
К слову на самом деле от задач сильно зависит, бывает наоборот задача написать такой код, чтобы в случае если кто то другой его получит — он мало что мог бы с ним сделать.
С другой стороны, если структура проекта не сложная, и если написать хорошую документацию то вполне возможно в некоторых случаях этот вариант будет лучше стандартных фреймворков.
А если учитывать опыт тысячи разработчиков и их стремление сделать код качественным и удобным, против одного контрибьютера самописных решений…
Для примера взять хотя бы простой компонентик файндера symfony.com/doc/current/components/finder.html неужели может быть что-то более простое и удобное при поиске файлов в файловой системе? ;)
Для примера взять хотя бы простой компонентик файндера symfony.com/doc/current/components/finder.html неужели может быть что-то более простое и удобное при поиске файлов в файловой системе? ;)
бывает наоборот задача написать такой код, чтобы в случае если кто то другой его получит — он мало что мог бы с ним сделать.
Не думаю что есть такие задачи. Как минимум вижу их глупыми.
если написать хорошую документацию
да не будет никто ее писать. Ну или хотя бы свой фреймворк будет основан на каких-либо существующих решениях а не полностью с нуля.
Словом я вам просто рекомендую попробовать реализовать что-нибудь что вы без фрейморков пишите хотя бы на каком-нибудь Silex.
symfony-gu.ru/documentation/ru/html/book/from_flat_php_to_symfony2.html почитайте эту статью например
Я никогда не забуду как бродил по реализации респонса в Symfony и увидел там вот это… Я радовался как ребенок от осознания что чуваки подумали о такой вот приятной мелочи…
Никогда не понимал необходимость fastcgi_finish_request, более того увидев это у меня возникает подозрение, что что-то не правильно спланировано, т.к. имхо единственное где оно может пригодится — заранее «сказать», что реквест отработал (готов) при этом продолжить выполнение. Но в этом случае вобщем-то имеем background (backend) job, который блокирует frontend воркера, что не есть, вернее совсем не гуд. Этим должен и в нормальных системах и занимается background процессинг (aka pipeliner и т.д.).
Простейшее средство например сказать nginx в респонсе, что после frontend upstream, он должен выполнить какой-нибудь url из background upstream.
Предупреждая вопрос зачем такое разделение — frontend должен быть отзывчив, backend — нет.
Простейшее средство например сказать nginx в респонсе, что после frontend upstream, он должен выполнить какой-нибудь url из background upstream.
Предупреждая вопрос зачем такое разделение — frontend должен быть отзывчив, backend — нет.
именно чтобы выполнить что-то после ответа, например отправить емейл или выполнить HTTP запрос кудато (например через pushstream отправить сообщение пользователю)
по поводу nginx — можете подсказать какой набор директив/заголовков вы имели ввиду?
по поводу nginx — можете подсказать какой набор директив/заголовков вы имели ввиду?
по поводу nginx — можете подсказать ...в респонс пыха:
header('X-NEW-BG-JOB: do_something_url $uid');
if ($upstream_http_x_new_bg_job != '') {
#do something after response;
}
Ну а дальше куда фантазия заведет, например формируем асинхронный вызов в Lua/Tcl/etc к url на background upstream.
ну с lua/perl и т.п. понятно, но держать логику приложения во фронтенде это как-то странно, при деплое еще и код в настройках nginx поддерживать как-то странно
Разделять «логику» приложения на front- и background- это не только не странно, но и единственно правильно. В настройках же вы поддерживаете (настраиваете) только связь front- и background-сервиса. Если хотите связь upstream-ов. Больше ничего. Никого же не смущает вызов например стороннего web-service. Почему вас смущает «вызов» своего «web-service»?
Я у себя в команде за неправильное использование fastcgi_finish_request (а оно практически всегда необосновано) по рученкам кривым сильно бобо сделаю…
Еще раз: любая работа, которая может быть (асинхронно) выполнена в тени, должна быть выполнена в тени!
Даже если вам это сегодня не нужно, завтра при росте нагрузки вам будет гораздо проще.
Я у себя в команде за неправильное использование fastcgi_finish_request (а оно практически всегда необосновано) по рученкам кривым сильно бобо сделаю…
Еще раз: любая работа, которая может быть (асинхронно) выполнена в тени, должна быть выполнена в тени!
Даже если вам это сегодня не нужно, завтра при росте нагрузки вам будет гораздо проще.
только почему для этого я должен передавать это через frontend, добавляя между бекендом и «тенью» (воркером) промежуточное звено? почему я не могу дергать свои сервисы из бекенда?
ну и то что вы физические увечия наносите своим сотрудникам и обзываете их ручки может сыграть с вами злую шутку, я со своими разговариваю например.
ну и то что вы физические увечия наносите своим сотрудникам и обзываете их ручки может сыграть с вами злую шутку, я со своими разговариваю например.
добавляя между бекендом и «тенью» (воркером) промежуточное звено?Это не пренципиально на самом деле.
На вскидку (по ощущениям если не ошибаюсь) как это сделали бы вы:
client -> fe-request -> nginx -> php-fe-upstream -> дергает be-url -> nginx -> be-request -> php-be-upstream -> bg-work;
|--> nginx -> fe-responce;
client -> fe-request -> nginx -> php-fe-upstream -> говорит nginx be-url -> nginx -> php-be-upstream -> bg-work.
|--> nginx -> fe-responce;
Разница совсем не существенна, если это все обернуто в API. И то и другое правильно. И тогда кстати в вашем случае fastcgi_finish_request перед вызовом be-request совершенно обоснован.
Замечу только, что в моем варианте я не должен заботится о том, что вызов be-url действительно асинхронный (за меня это сделает nginx). В вашем же варианте это нужно учесть при вызове be-url (т.е. действительно только дергает), иначе воркер фронэнда «подвисает» на время выполнения bg-work в тени.
Все остальное же от балансировки до конфигурации be-upstream одинаково.
У себя я юзаю fastcgi_finish_request для того чтобы сбросить в логи все изменения, отослать накопленные письма и сбросить очередь задач в реббит. Все это лежит «исторически» в onEndRequest (Yii1) и занимает ненулевое время. И благодаря fastcgi_finish_request перед всем этим делом, веб приложение стало намного отзывчивей, причем не только метрики, но и пользователи сразу же заметили эти изменения.
Так что пользы вагон с тележкой. И то что симфони делает это из коробки это крайне хорошо.
Ваши подозрения в «неправильной планировке» мягко говоря необоснованны.
Если контент готов и отослан клиенту, то отправка «все ок — мы больше вам ничего слать не будем» очень логична.
Так что пользы вагон с тележкой. И то что симфони делает это из коробки это крайне хорошо.
Ваши подозрения в «неправильной планировке» мягко говоря необоснованны.
Если контент готов и отослан клиенту, то отправка «все ок — мы больше вам ничего слать не будем» очень логична.
Ваши подозрения в «неправильной планировке» мягко говоря необоснованны.Озвучу тогда мои подозрения по поводу вашей компетентности: вы вероятно ни разу плотно нагруженый сайт не делали, потому как отзывчивость сайта путаете с отзывчивостью одного единственного запроса (на который вы делали fastcgi_finish_request).
Для тех кто в танке: любая работа, которая может быть (асинхронно) выполнена в тени, должна быть выполнена в тени!
Frontend делает только работу по формированию и отдаче контента. Остальное дело техники раскидать ли background на другие сервера, выдать ли другой priority/affinity, отложить ли эту работу (в очередь) и т.д. и т.п.
Это по умолчанию. Вы можете после отправки запроса вообще ничего не делать. Но по умолчанию симфони всю почту отправляет уже после отправки запроса, тем самым уменьшая задержки для пользователя. Вы можете вместо этого в очередь все пихать. Никто вас ни в чем не ограничивает. Но как вариант по умолчанию как по мне идеально.
ИМХО выбор очень сильно зависит от массы обстоятельств: что за проект (по своей сути и масштабу), один ли ты над ним работаешь, каковы привычки и так далее.
Мой код вообще ужасен в общем понимании — это либо небольшие файлы-геттеры в 20-30 строк, которые получают данные из базы данных и выводят их в JSON или в ином кастомном формате (в последнее время отдаю предпочтение JSON, это стабильнее и гибче) для отправки через AJAX, либо просто блоки неструктурированного кода прямо в файле с разметкой (такого же или меньшего размера), либо вообще дикие макароны, где очень хочется динамически формировать блоки с разметкой исходя из неких условий, и при этом не задействовать принципиально JS, чтобы страница отрисовывалась как надо сразу. И вроде, поддерживаю более-менее весь этот ахтунг.
Хотя порой возникает мысль, не было ли бы проще/красивее писать код как-то иначе.
Мой код вообще ужасен в общем понимании — это либо небольшие файлы-геттеры в 20-30 строк, которые получают данные из базы данных и выводят их в JSON или в ином кастомном формате (в последнее время отдаю предпочтение JSON, это стабильнее и гибче) для отправки через AJAX, либо просто блоки неструктурированного кода прямо в файле с разметкой (такого же или меньшего размера), либо вообще дикие макароны, где очень хочется динамически формировать блоки с разметкой исходя из неких условий, и при этом не задействовать принципиально JS, чтобы страница отрисовывалась как надо сразу. И вроде, поддерживаю более-менее весь этот ахтунг.
Хотя порой возникает мысль, не было ли бы проще/красивее писать код как-то иначе.
А что останавливает? Если вам комфортно среди макарон, то почему бы нет? Есть такая мысль что чистый код это код, который соответствует ожиданиям. Мол когда мы смотрим в код который что-то делает и понимаем как оно это делает. Другими словами чистый код это скучный код.
Я просто знаю, что такой код писать — стыдобища. Но просто проекты таковы, что надо писать «побыстрее, и чтобы работало», и изучать на старте проекта новую технологию уже поздно, плюс боязнь тормозов (фреймворки много лишнего делают часто), плюс привычка к полному контролю: чтобы что-то поменять, вроде той же паджинации, в случае готового компонента придётся лезть в его код и разбираться в нём, а так у меня допустим уже есть свой, который смотрится хуже, но на сто процентов работает как надо, и кочует из проекта в проект.
А так ничего. Сейчас вот почитал этот текст и комменты, подумал — и решил попробовать счастья с Symfony 2. В своё время читал про Code Igniter, не впечатлило почему-то. Даже настройка роутинга отпугнула, по сравнению с привычным мне добавлением 5-8 строк в .htaccess напрямую.
А так ничего. Сейчас вот почитал этот текст и комменты, подумал — и решил попробовать счастья с Symfony 2. В своё время читал про Code Igniter, не впечатлило почему-то. Даже настройка роутинга отпугнула, по сравнению с привычным мне добавлением 5-8 строк в .htaccess напрямую.
Я бы предложил Laravel (версия 4.2 идеальна для старта, версия 5.1+, текущая, более серьёзный инструмент и ему сложнее научиться с нуля), а потом уже начать думать о симфони, стоит ли оно того или нет. Ходят слухи, что разработчики на симфони (не будем тыкать пальцем, но есть такие знакомые и не один) сами его ругают из-за избыточности и готовы перейти на указанный выше фрейм.
ругают из-за избыточности и готовы перейти на указанный выше фрейм
избыточность… как много в этом слове… обмажутся своими бандлами и потом страдают. В целом Laravel неплохой вариант для быстрой разработки, особенно пятая версия. Но ORM… тут уже сильно зависит от задачи.
Основная проблема — фреймворки это просто набор компонентов. А большинство пытается стандартный сэт компонентов конкретного фреймворка притянуть для решения всех их проблем.
Верно, вспомнил, в качестве ORM так же советуют Propel, как не столь безумный, как доктрина и получше нативного элоквинта. Судя по тому что я видел в пропеле (но не работал с ним), мне тоже нравится подобный вариант. Верно ли подобное утверждение? Т.е. стоит попробовать перелезть на него вместо натива?
Лично мне (повторюсь, это лишь мое мнение) в принципе не нравится концепция active record или active state. Она простая как пробка, и в принципе для простых вещей это дико удобно. Но если вам важна целостность данных, то такие маленькие мелочи как транзакции и т.д. приходится контролировать самому. А так же частенько нужно учитывать то как данные в принципе сохраняются. Чем мне нравится доктрина — так это коммит изменений. То есть на момент flush-а мы одной транзакцией записываем все изменения одновременно, причем именно то что изменилось а не заменяем всю запись. Ну и так же наличие identity map позволяет нам организовывать самое настоящее взаимодействие наших бизнес объектов вообще не беспокоясь о том что у нас внезапно могут возникнуть копии сущностей только потому что сущности были загружены по связям.
Доктрина это крайне сложное решение, которое дает полную абстракцию от базы данных, чем не может похвастаться ни одна другая ORM. Тот же пропел во второй версии вроде как тоже собирается стать реализацией шаблона data mapper, как когда-то оным стала Doctrine2 (может кто не знает но первая доктрина была так же active record). А ну и да, использовать доктрину с чем-то типа mysql дико не удобно, а вот postgresql — другое дело (или любая другая СУБД поддерживающая последовательности вместо автоинкрементов)
С другой стороны, есть масса других подходов при которых AR используется в контексте своей абстракции и т.д. но я не видел подобных систем (только слышал о них), обычно работа с данными организуется весьма примитивно. А для систем где сохранность данных в самом большом приоритете как не странно все намного проще — event sourcing, все данные имутабельные, мы никогда ничего не апдейтим, только добвляем. Это снимает все проблемы связанные с отлеживанием изменний (нет изменений нет проблем), конкурентными запросами на редактирование и т.д. В этом ключе ORM как таковая вообще не нужна.
Словом… все зависит от задачи и исключительно от задачи. Мне вот намного проще применять Doctrine2 для организации domain-centric архитектур. Да даже банально прототипы набрасывать на ней намного удобнее и местами быстрее. Но что бы все было просто и удобно приходится долго и нудно изучать документацию и разбираться как все это работает. А без этого шансы споткнуться сильно высоки за счет спрятанной сложности.
Доктрина это крайне сложное решение, которое дает полную абстракцию от базы данных, чем не может похвастаться ни одна другая ORM. Тот же пропел во второй версии вроде как тоже собирается стать реализацией шаблона data mapper, как когда-то оным стала Doctrine2 (может кто не знает но первая доктрина была так же active record). А ну и да, использовать доктрину с чем-то типа mysql дико не удобно, а вот postgresql — другое дело (или любая другая СУБД поддерживающая последовательности вместо автоинкрементов)
С другой стороны, есть масса других подходов при которых AR используется в контексте своей абстракции и т.д. но я не видел подобных систем (только слышал о них), обычно работа с данными организуется весьма примитивно. А для систем где сохранность данных в самом большом приоритете как не странно все намного проще — event sourcing, все данные имутабельные, мы никогда ничего не апдейтим, только добвляем. Это снимает все проблемы связанные с отлеживанием изменний (нет изменений нет проблем), конкурентными запросами на редактирование и т.д. В этом ключе ORM как таковая вообще не нужна.
Словом… все зависит от задачи и исключительно от задачи. Мне вот намного проще применять Doctrine2 для организации domain-centric архитектур. Да даже банально прототипы набрасывать на ней намного удобнее и местами быстрее. Но что бы все было просто и удобно приходится долго и нудно изучать документацию и разбираться как все это работает. А без этого шансы споткнуться сильно высоки за счет спрятанной сложности.
Попробуйте использовать некоторые компоненты Symfony вместо целого фреймворка. Я пересобрал свой проект используя некоторые компоненты и уже который месяц абсолютно счастлив. У Фабьена есть прекрасный цикл статей как это сделать: http://symfony.com/doc/current/create_framework/index.html
Просто если у вас есть своя технология, которая вас устраивает не надо ее ломать. Возьмите нужные компоненты и просто сделайте свой код меньше и понятнее.
Просто если у вас есть своя технология, которая вас устраивает не надо ее ломать. Возьмите нужные компоненты и просто сделайте свой код меньше и понятнее.
Я просто знаю, что такой код писать — стыдобища
Дело не в том что это «не круто», просто поддерживать этот код сложнее, дороже и противнее.
плюс боязнь тормозов (фреймворки много лишнего делают часто)
Для вас есть разница 20 милисекунд страница генерится или 50? Это вам кажется что они много лишнего делают. Взять тот же symfony и проблему с отправкой почты. Допустим вам надо сделать отправку уведомления всем участникам ветки комментариев. Для этого после добавления комментария мы берем список подписчиков и для каждого отправляем письмо. Допустим сформировать и отправить письмо на старом добром PHP — это где-то милисекунда. Не много, да? А теперь представим что у нас сотня подписчиков. И это уже 100 милисекунд. То есть на добавление комментария, то что важно для пользователя, мы затратили 20-30% времени обработки запроса. Что же делает симфони (при условии что мы используем php-fpm) — оно из коробки предоставляет нам in memory spool, при котором отправка сообщения происходит уже после того как клиент получил ответ и спокойно закрыл соединение. То есть для пользователя запрос будет длиться уже не 120 милисекунд а всего 20 милисекунд. И таких вот мелочей и юзкейсов фреймворки покрывают огромное множество.
а так у меня допустим уже есть свой, который смотрится хуже
фреймворки как бы не запрещают использовать свои решения. Адаптируйте и пользуйтесь.
по сравнению с привычным мне добавлением 5-8 строк в .htaccess напрямую.
для небольших домашних проектов это все конечно норм, но для коммерческих проектов лучше не делать подобного, все же 2015-ый год на дворе.
С CMS мне не комфортно работать ровно по тем же причинам, кстати: пока это как конструктор, всё весело и просто, но как только возникает необходимость править модули (а они не всегда просто устроены, и код там не всегда идеален) — то труба. В конфигурацию в админке не всегда вынесено много опций, часто вообще почти ничего не вынесено, если разработчик был ленив.
За 4 года PHP-рынок изменился реально очень сильно. Composer поменял сразу очень многое. Кто к нему не приспособился, резко потеряли сторонников. Laravel взлетел как из пушки.
мой выбор Zend Framework 2 — бессмертная классика! :)
ну и Энтерпрайз, паттерны и все такое.
Жду выхода версии 3.
ну и Энтерпрайз, паттерны и все такое.
Жду выхода версии 3.
А я использую Silex + Symfony. И я в них уверен :)
Результаты опросов на хабре сводятся к единной логике: я не ездил на вашей ламборджини, но у моего любимого велосипеда колеса побольше
Спасибо, из этой статьи почерпнул информацию, о том, какие фреймворки вообще используются часто в реальной работе, а из комментов тоже много интересной инфы узнал.
С веб-фреймворками до сего момента вообще дела не имел (если не считать Drupal, да и тот в качестве не совсем фреймворка, а скорее CMS с расширенной/допиленной функциональностью), но давно хотел в эту среду окунуться. Мало того, с Composer'ом особо дела не имел, так что сегодня для меня день открытий.
Сижу, ковыряюсь в доке по Yii2, попутно осваиваясь на практике с этим зверем.
Хабру в очередной раз спасибо!
С веб-фреймворками до сего момента вообще дела не имел (если не считать Drupal, да и тот в качестве не совсем фреймворка, а скорее CMS с расширенной/допиленной функциональностью), но давно хотел в эту среду окунуться. Мало того, с Composer'ом особо дела не имел, так что сегодня для меня день открытий.
Сижу, ковыряюсь в доке по Yii2, попутно осваиваясь на практике с этим зверем.
Хабру в очередной раз спасибо!
Хорошая попытка, PHPixie, но нет. )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Результаты опроса популярности PHP фреймворков от Sitepoint