Laravel — PHP Framework для ремесленников

    Laravel PHP Framework
    Laravel — это чистая и стильная основа для разработки. Он избавит вас от спагетти кода. Поможет вам создавать прекрасные веб-приложения используя простой и выразительный синтаксис. Разработка должна доставлять удовольствие. Наслаждайтесь глотком свежего воздуха.

    Еще один PHP фреймворк, подумаете вы. Возможно, но он стоит того, чтобы на него посмотреть.
    Фреймворк довольно молодой, 2011 год. Использует PHP 5.3. У него уже хорошее сообщество, много форков. Уже дорос до версии 3.0.

    Взглянув на довольно хорошую документацию, у меня промелькнули параллели с одним хорошим фреймворком, который я давно знаю. По сути этот фреймворк представляет некую солянку хороших решений, взятых с нескольких фреймворков.

    Что умеет

    Bundles ( Модули ) — имеется репозиторий с обширным количеством бандлов.

    The Eloquent ORM — ActiveRecordORM, умеет строить связи ( many to many, one to many, one to one )

    Migrations — думаю, правило хорошего тона.

    Redis — да, noSQL из коробки.

    Environments — в зависимости от домена, может подгружать те или иные конфигурационные файлы.
    Скажем, пропишем в файле paths.php
    $environments = array(
    
        'local' => array('http://localhost*', '*.dev'),
    
    );
    

    Теперь, если мы зайдем с домена начинающегося на localhost или заканчивающегося на .dev. Фреймворк будет подгружать файлы конфигов с папк application/config/local/* вместо application/config/*

    IoC Container — методы для создания и, опционально, инстанцирования и хранения ссылок синглтонов. Это также значит, что вы будете меньше нуждаться в подгрузке внешних библиотек.

    Class Auto Loading — так же, можно переопределить в конфиге любой системный класс.

    Работа из под CLI — устанавливайте\создавайте миграции, бандлы, запускайте нужные роуты (крон скажем).

    Имеется asset менеджер. Весь код вынесен за пределы публичной директории.

    Возможностей из коробки довольно много, кому интересно, тот заглянет глубже.

    Ну и на последок, пару ссылочек.

    Скачать — laravel.com/download
    Документация — laravel.com/docs настолько простая, что даже ребенок разберется :)
    Github — github.com/laravel
    Скринкасты — www.screenr.com/user/laravel
    Русское сообщество — laravel.ru
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 67
    • +2
      Хм, много интересных вещей там есть, и удобных, но очень не понравился подход, когда на каждую глобальную сущность у них свой класс, в котором куча static методов. Хотелось бы одну общую точку, например как в Yii, Yii::app()->… а тут много-много всего самостоятельного статичного. Ну и еще немного не понравились nested controllers, это значит если я хочу вложенность в 3-4 сделать, то это будет One_Two_Thre_Four_Controller, прям как имена ZF :D Но в целом понравился) Надеюсь другие разработчики, в том числе Yii, возьмут отсюда тоже много классных идей)
      • –1
        Если глянуть на Kohana, то там тоже, куча статических классов. Но там мало чего из коробки есть.
        • 0
          ну я и говорю, что не очень нравится эта куча статических классов. Из коробки действительно тут очень много всего, чего например в том же Yii хотелось, посмотрим что будет дальше с эти fw.
          • +1
            Давайте будем честными и подчеркнем, что «не нравится» — это не совсем аргумент, уж простите мне мою прямоту.
        • 0
          Уже просмотрели и всё хорошее взяли на заметку ;)
          • 0
            Так давайте быстрее уже :)
        • 0
          По сути это может стать альтернативой YII. Уж больно они тянут со своей 2-ой веткой, а тут есть все что хотят реализовать в Yii. Хотя я все равно не вижу никаких реальных доводов для того что бы использовать этот фреймворк. Как по мне ближайшее время вряд-ли что-то круче симфонии второй появится.
          • 0
            Хм, не соглашусь с вами насчет «реальных доводов для того что бы использовать этот фреймворк», пусть посмотрел бегло, но все же у этого fw есть много полезных вещей и хорошая структура, что в сумме даст ускорение + улушчение качества разработки, разве это не основополагающе? Вопрос в том, что есть подсознательное «не хочу учить что-то новое», но это уже другие проблемы :)
            • +6
              Беда в том что я лично не увидел ничего нового и ничего «лучше». В симфони есть те же бандлы, тот же Dependency injection и т.д. И реализация там много более интересна (хотя бы аннотации, раутинг и прочие плюшки, которые здесь реализованы довольно стандартно.

              The Eloquent ORM и миграции. Мне больше по душе Doctrine ORM. Я пользовался многими и субьективно, лично для себя, ничего лучше я просто не нашел. Апдейт схемы делает наличие миграций необязательными. Очень редко они мне были нужны. Вообще все намного более лаконично. Поправил модель, закомитил. Другой человек обновил у себя, выполнил команду и готово. А так после изменения модели приходится и миграцию писать. Я ленивый человек и не люблю лишние телодвижения для достижения желаемой цели. Да и AR любит память жрать. Тут к слову было бы неплохо разработчикам фреймворка подготовить какой-нибудь бенчмарк.

              no-sql из коробки — ну… клево, да. Правда у Doctrine тоже есть ODM.

              Обширная коллекция бандлов — чуть менее 100. Большая часть из которых лишь сервисы для DI. На то он и DI что бы можно было легко любую библиотеку в сервис превратить.

              Подытожив: я не буду пользоваться этим фреймворком. Покрайнемере пока не увижу явных плюсов перед симфони 2. Ну или по работе придется.

              p.s. Я сам был приверженцем Yii, но по работе заставили разбираться с Symfony 2. По началу да, плевался, но затем… словом, как я уже говорил, врят-ли ближайшее время появится что-то кардинально новое.
              • 0
                Да, полностью согласен по поводу Symfony и без упрека в сторону Laravel. Сейчас пишем проект на Symfony 2.3 — полностью покрывает все необходимое в разработке — (Хотя часто вижу высказывания, что порог вхождения в Symfony высокий — я думаю просто нужно привыкнуть к тому, что можно получить все через DI). И по поводу аннотаций — просто сказка. Нужно ACL повесить над роутингом — пожалуйста, добавляем в аннотацию и все (предварительно подключив бандл JMSSecurityExtraBundle ).
          • –14
            «recovery mode» на хабре…
            Так и думал что напишут про этот фреймворк :)
            • 0
              причем здесь recovery mode?
              • –13
                Ошибся.
                Спасибо за пост!
              • –2
                Супер. Всю карму слили
                • 0
                  ой беда, огорчение
              • +8
                • –13
                  Ещё одна попытка скопировать Rails. Смотрел только ORM, почти 1 в 1 ActiveRecord, только с PHP синтаксисом смотрится не очень.
                  • +10
                    Паттерн Active record был описан в 2003-ем году, когда как RoR вышла в 2004-ом. Объясните же мне, почему все слизано именно с RoR?
                    • –14
                      Потому что ActiveRecord – это не только название паттерна, но также и название библиотеки Rails. И не все, кто говорят «ActiveRecord» даже слышали про Фаулера.
                      • +14
                        Гениальное логическое умозаключение. Я так подозреваю, что если в рельсах есть Controller, то в остальных fw на других ЯП, в которых есть данный тип объектов, тоже все слизано с рельс? мда…
                        • –2
                          При чем тут слизано? Вы слышали про термин «контекст употребления»? В зависимости от контекста это имя собственное может значить либо одно, либо другое. В примере сверху очевидно, что речь шла про _библиотеку_, а не про паттерн. Но конечно легче троллить и умничать, чем знать о существовании и того, и другого.
                          • –1
                            K чему наезд?
                            «И не все, кто говорят «ActiveRecord» даже слышали про Фаулера.» — это же тонкий стеб над «Ещё одна попытка скопировать Rails. Смотрел только ORM, почти 1 в 1 ActiveRecord, только с PHP синтаксисом смотрится не очень.».
                            • 0
                              Блин, это тоже называется фрейсворком… ну ты подумай, все воруют у RoR
                              • 0
                                буд-то это плохо…
                      • +15
                        Когда уже сделают чтобы людей подписанных на ruby не пускали в php хабы.
                        • +1
                          Смысл?
                          Есть среди них люди с рельсами головного мозга, но есть и вполне адекватные.
                          • +3
                            Просто у некоторых в голове версии гемов конфликтуют )))
                      • +5
                        Я так и не понял, чем-же этот фреймворк круче Symfony или других фреймворков? Например при задании в поиске тупо: «i18n» мне ничего не выпало? Получается, интернационализация отсутствует? Хорошо, а ОРМ взяли откуда — контрол+це, контрол+ве? Редис?! Он типа везде стоит как дефолт, правда? И что-же получается? Как всегда, фреймворк для быстрого написания (говно)кода, чтобы код веб странички не выглядел как говнокод и не казался слишком «гламурно-тупым» для новичков? Зато да, используете «фреймворк».
                        Или я чего-то не усёк?

                        ПС: я так, маслица в огонёк подлил. Если чё, минусуя обьяснайте в чём не прав…
                        • 0
                          Каждый новый FW теперь обязан быть круче Symfony или других фреймворков?
                          Как сегодня было сказано в одном из топиков:
                          это всего лишь дело вкуса
                          • +3
                            Дело вкуса это конечно хорошо, но обычно выбирают инструменты все же для работы. А для работы важно что бы это работало. Причем желательно что бы и через год фреймворк развивался, поддерживался, количество расширений росло. Рассматриваются перспективы, качество реализации и т.д. и т.п.

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

                            Вот если бы у этого фреймворка была более узкая целевая аудитория, или же он позволял реализовывать какие-то задачи на порядок быстрее, то я бы с удовольствием рассмотрел этот вариант.

                            Почему никто не сделает нормальный человеческий демон на PHP? (их уже много конечно, но тут развернуться в плане возможностей и альтернатив есть куда) Ну или там, аналог CoffeeScript для php (какие-нибудь надстройки, синтаксический сахар, нормальные названия методов, функций и прочего) для более удобной и функциональной разработки? (в симфони вот ввели аннотации, которые, судя по всему, в сам язык введут ой как не скоро, если вообще введут)
                            • +2
                              С таким подходом:
                              Sinatra не нужен в мире Ruby, поскольку RoR – мейнстрим.
                              Mootools, CoffeeScript не нужны в мире JS — есть jQuery и JS сам по себе.
                              Play не нужен в Java – нафига, уже есть Spring.

                              Продолжать?
                              • 0
                                Ваша цепочка не совсем корректна:
                                Я хоть и далек от рабби, но синатра больше похожа на микрофреймворк. А вот RoR — тормознутый монстр (извините за бестактность, быть может мои впечатления устарели). Цели использования у них изначально разные, разные целевые группы. Тут все гуд.

                                Mootools сравнивать с jQuery тоже несколько некоректно. Если вы выбираете библиотеку для работы с DOM то да, mootools вам не нужен. Но если вы пишите сложное приложение то вам понадобится более мение удобная структура. Хотя сейчас есть backbone+underscore+jquery.

                                кофескрипт — тут я промолчу. Лично мне он никогда не нравился, потому субьективно я настроен против. Хоть и понимаю что штука возможно полезная.

                                Play и Spring не видел. С Java знаком лишь на уровне универа. Мне больше как-то C# подуше.

                                Я не призываю остановить развитие так как есть какой-то модный фреймворк. Все развивается, и в один момент фреймворк может уже не соответствовать требованиям. Я о том, что если фреймворк ничем не лучше при той же сфере применения — он не особо нужен.
                                • +2
                                  Я не смотрел и не щупал сабж, возможно, там все плохо, а может быть есть и свои плюшки.
                                  Да тот же symfony для решения многих задач избыточен, и хотелось бы иметь что-то полегче и шустрее.
                                  А выбор — это же здорово, глядишь и получится что-то такое, что все скажут wow.

                                  PS Прибегут апологеты руби и залинчуют вас за «рабби». Если что, я не при делах :)
                                  • +2
                                    Да, не спорю, симфони зачастую избыточен. Как допустим использование MySQL там, где хватило бы обычных файлов ну или хотя бы простенькое NoSQL Хранилище. Есть множество микро-фреймворков. Тот же Silex, который построен на симфони. Да много их разных. Но ведь и сабж избыточен. Так зачем он мне? у меня уже есть неплохой фреймворк который с лихвой покрывает все мои нужды. Мне вообще концепция узконаправленных библиотек нравится, и не радует меня попутки реализовать универсальную систему. Чем мне нравится симфони, и пожалуй это ее основное преимущество, ты не привязываешь компоненты системы к архитектуре фреймворка. Это делает все очень гибким.

                                    PS Прибегут апологеты руби и залинчуют вас за «рабби». Если что, я не при делах :)

                                    Я заслужил… чего уж там.
                                    • 0
                                      Мейнстрим хорош тем, что вам не придется писать много документации и объяснять новичкам особенности своих хипстерских фреймворков. Симфонист разберется в симфони проекте гораздо быстрее, чем в laravel проекте и т.п.

                                      Фреймворк это набор реализованных паттернов. И говорить о гибкости как-то странно. Все равно рано или поздно что-то придется допиливать самим.
                                    • 0
                                      Истина, как всегда, где-то посередине: руби раби рабби

                                      =)
                                  • +1
                                    Во все времена все новое должно было доказывать свою состоятельность. Каждый раз, когда читаю о том, что вышел новый PHP-фреймворк, убеждаюсь в двух вещах:

                                    1. Что сделал правильный выбор, выбрав Kohana,
                                    2. Что правильно делаю, изучая Erlang и чуть-чуть NodeJS.

                                    Хотя к PHP у меня нету противления, как у некоторых ненавистников. Это инструмент со своей конкретной целью.
                                    • +1
                                      В буржунете сейчас идет волна ня-обожания Laravel, особенно после поста philsturgeon.co.uk/blog/2012/05/laravel-is-awesome. (Fuelphp, кстати, впал в немилось, из-за планируемого перехода на PSR-1 с кемел-кейсом, и вообще он уже не ня). И такое ощущение, что народ не видел Кохану вообще. Почти никто её не вспоминает и не сравнивает с ней. Такое ощущение, что все до сих пор сидят на CodeIgniter и отсутствие singleton для них уже мегапрорыв и разрыв шаблонов.

                                      Интересно, почему Кохана растеряла всех codeigniter-свитчеров? Ведь это прекрасный простой (если не лезть в глубь и работать по шаблону) фреймворк, как раз для ЦА laravel?
                                      • +2
                                        Слишком частое изменение API, не совместимые с предыдущими версиями. Например, код под 3.1 не будет работать на 3.0. Плюс, не поспевает документация, мало наработок (это уже следствие изменения апи), игнор девелоперов со стороны разработчиков фреймворка и т.д.
                                        • 0
                                          Я с вами соглашусь, но только отчасти. Последний раз изменение API затронуло только работу с конфигами (это вообще была ерунда). Единственное серьезное изменение было, на моей памяти, связанное с контроллерами. И тут вы не правы — как раз-таки, код, написанный под 3.2 в этом плане был совместим с ранними версиями. А это означает, что перейти к поддержке ядра 3.2 было можно заранее. Я могу всего не помнить, конечно, но особенных трудностей не ощутил.

                                          Что касается отсутствия библиотек, то, опять же… лично я такого не ощущаю — была определенная канитель с визуальным редактором, но мы решили запилить свой файловый браузер и вытащить его в модуль. Пожалуйста, теперь все четко. Это же опенсурс — если чего-то не хватает, никто не мешает запилить это.

                                          По поводу же отсутствия желания прислушиваться у разработчиков я согласен только отчасти. Часто к ним пристают с какими-то глупостями. Вы почитайте форум — иногда там творится АДЪ.
                                          • +1
                                            А до этого, с 3.0 на 3.1, меняли Validate на Validation + Valid, вводили Request — это довольно обширные изменения были. brotkin.ru/2011/01/10/ko-31-rc1
                                            • 0
                                              Вспоминл, да. Только, почему-то, я к ним не отнесся так болезненно… Все довольно гладко у меня прошло.
                                            • +3
                                              В 3.1 появился response, изменилась валидация, пропали фильтры и callback-и в валидации (которые, между прочим, часто использовались).
                                              В 3.2 изменились конфиги, изменился request (например, пропал метод url), кое-какие мелкие изменения.
                                              В 3.3 изменились Controller, HMVC, HTTP_Exception (это вообще весело), request (снова! пропал redirect, изменились параметры в factory, пропал response), Autoload (!!! вообще ломающий старый код) и т.д.

                                              В общем, каждое обновление ломает рабочий код (
                                              • 0
                                                У меня настроение под конец дня ироничное… с другой стороны, можно считать, что каждая новая версия Коханы — отдельный фреймворк.

                                                Я как-то не следил за развитием ветки 3.3 в Кохане — в ближайшее время ознакомлюсь. Очень интересно, чем они все это объясняют.
                                          • +1
                                            Есть такая работа — новшества прославлять (с).

                                            Я у Коханы внутри ничего такого сложного не обнаружил. Единственная сложность, с которой столкнулся — что в интернете гайды и хауту по ней пишут люди, которые решают задачи, а не создают инструменты для решения задач. К примеру, этот знаменитый монстр, демонстрирующий работу oAuth. Ужас-ужас.
                                            • 0
                                              Раньше у Фила была другая работа — разрабатывать CodeIgniter и FuelPHP. Поэтому такой вот поклон в адрес прямого конкурента людей поразил.
                                              • 0
                                                Ну посмотрим, что из этого выйдет.
                                                • +1
                                                  На самом деле это это был не столько поклон, сколько оправдание неповоротливости CodeIgniter в плане технологических улучшений — ведь и правда, вносить кардинальные изменения в движок, которые ломают функциональность работающих приложений, — это проявление неуважения к пользователям продукта. Кстати, сабж на протяжении трёх версий менялся кардинально, но это можно списать на его молодость.
                                          • 0
                                            Запоздало влез, но да, Mootools, CoffeeScript не нужны в мире JS — есть jQuery и JS сам по себе. Тут полностью согласен, не нужны они там. Про остальные технологии не знаю.
                                      • +4
                                        «каждый защищает свое г**но» — тут уже больше дело вкуса… так как есть люди для которых Zend круче всего на свете, у других это Yii и т.д. по списку. Говно можно писать и на Symfony, и на всех остальных, так что, не нужно тут поднимать шуму, или быть уверенным что есть FW который не даст написать говно-код.
                                        • 0
                                          Интернационализация там есть.
                                          Он не круче, он проще. Если Symfony это RoR, то Laravel скорее Sinatra. Taylor Otwell его начал писать год назад, чтобы с чистого листа сделать простой и человечный php-фреймворк, без груза обратной совместимости и с радостями 5.3 (а именно замыкания) и наработок из RoR и других фреймворков. Получилось в целом неплохо. Это для людей, которые начинали не с Zend, а с Codeigniter. Для ремесленников, а не для живописцев.
                                          • –1
                                            Вот тоже, слоган довольно странноватый. Обратил внимание, да.
                                        • +2
                                          Перевод некоторых статей на русский: laravel.ru/
                                          Полезные ресурсы и ссылки для quick start: laravel.ru/forum/viewtopic.php?id=16

                                          Про laravel обещал написать Александр Макаров (Sam Dark), один из разработчиков Yii. C вот такой вот затравкой, опубликованной неделю назад в твиттере:
                                          «Смотрю фреймворк laravel. Некоторые штуки красивы, но есть и фатальные для выстраиваемых на нём приложений ошибки.»
                                          • +1
                                            • 0
                                              HTML::macro('my_element', function()
                                              {
                                                  return '<article type="awesome">';
                                              });
                                               
                                              echo HTML::my_element();
                                              

                                              Я, признаться, слегка обалдел, когда такое увидел. Это же как надо ненавидеть HMVC.

                                              Но я не холивары сюда разводить пришел. Мне интересно, вот вы пишете про ORM:
                                              Сами отношения классические. Такие, какими они были во времена становления Rails и Prado.
                                              А что вы имеете в виду, расскажите подробнее?
                                              • 0
                                                Четыре стандартных типа отношений: HAS_ONE, HAS_MANY, BELONGS_TO, MANY_MANY.
                                                • 0
                                                  Пардон, хотел узнать про нестандартные
                                                  • 0
                                                    Нестандартно будет в Yii2. Там не будет, например, MANY_MANY. Да и вообще каких-либо ограничений на тип и способ связей.
                                              • 0
                                                Так и не встретил раздела «Итак, фатальные для меня штуки». А было бы интересно.
                                                • 0
                                                  Самые фатальные в разделе «ORM, из нехорошего» + излишнее использование статики.
                                                  • 0
                                                    «Массовое присвоение в ORM включено по умолчанию».
                                                    В условиях необязательной валидации в моделях разработчик теоретически может выстрелить себе в ногу. Понятно, что с нашей точки зрения он сам себе кузнец своего счастья, но с точки разработчика фреймворков это серьезная уязвимость.
                                              • +1
                                                Имеет право на жизнь! Однако от статьи я ожидал раскрытия темы, примеров кода, примеров приложений/сайтов исполненных на данном FW. А так… просто ссылка: Тут вот такое появилось — сходите по ссылке…
                                              • 0
                                                Выше много уже было сказано о разном. И про ORM, и про Symfony… даже про RoR — а я скажу про HMVC.

                                                Уже как-то привык абстрагироваться от ядра в Kohana (да, глобальная область там заполнена статичными и не очень классами), но это тоже дело вкуса… Надо где-то улучшить? Без проблем… где-то баг, в какой-то библиотеке? Ничего страшного — все решим.

                                                Как причина номер два: я говорил, говорю и не перестану говорить, что наличие assert-функционала лично для меня является скорее минусом, чем плюсом. Я не вижу никаких препятствий тому, чтобы написать пару phing-тасков, которые будут сливать всю статику в один файл, сжимать ее чем угодно (некоторые даже гзипуют ее и кладут два варианта — так они любят свои сервера)… да блин, можно даже png/jpeg оптимизировать перед деплоем…

                                                Но самое главное — это HMVC. Точнее, его отсутствие.

                                                Так что пользоваться не стану.
                                              • 0
                                                их ОРМ (Eloquent) очень кривой. например вот как работает eager loading:

                                                foreach (Book::with('author')->get() as $book)
                                                {
                                                echo $book->author->name;
                                                }
                                                In the loop above, only two queries will be executed:

                                                select * from books

                                                select * from authors where id in (1, 2, 3, 4, 5, ...)


                                                Та же кохана делает такое одним запросом с лефт джойнами.
                                                Представте себе теперь что у вас 10000 books, в случае ларавел алогоритм выберет все 10000, пройдет по ним, соберет айдишки, создаст запрос с айдишками через кому (кстати если если нужно поддгрузить больше связей то запросов будет больше, и учтите что есть ограничение на размер параметров в IN ), потом пройдется по масивам еще раз и соединит books и authors. Памяти выжрет вагон.

                                                Вот в той же PHPixie о которой я писал создатся один запрос с джойнами и в памяти всегда будет только 1 книга и ее автор (так как будет использоватся курсор для прохода по строчкам резульата запроса).

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.