Данная статья предназначена для начинающих веб-разработчиков, а также тех, кто хочет понять, для чего стоит изучить PHP-фреймворк Laravel и какую экосистему он нам предлагает. Статья написана на момент актуальности Laravel версии 5.4, в августе 2017 выйдет релиз Laravel 5.5, который предоставляет ещё больше возможностей.
Содержание:
- Введение в веб-разработку, что было раньше и что сегодня
- Начало создания веб-проекта
- Этап первый – процесс написания кода
- Этап второй – тестирование кода
- Этап третий – сборка проекта
- Этап четвёртый – развёртывание (deploy) кода
- Итоги
- Основные возможности PHP-фреймворка Laravel
- Полезные ссылки
Введение в веб-разработку: что было раньше и что сегодня
В данной статье хотелось бы рассказать о том, что такое PHP-фреймворк Laravel и как благодаря этому фреймворку начинающий веб-разработчик может расширить свой кругозор, а также поднять свой культурный уровень разработки. Попытаемся раскрыть тему создания веб-проекта и помочь начинающим.
Инженер, программист или веб-разработчик?
Если 30 лет назад инженер и программист был один и тот же человек, и можно было с уверенностью сказать, что он даже мог починить электронику, то сегодня, благодаря техническому прогрессу и развитию технологий мы имеем множество языков программирования, специализаций и направлений, для изучения которых одному человеку просто физически не хватит времени. Скорее всего Ваш сосед программист не в состоянии починить смартфон, хотя он может написать приложение для этого смартфона.
Сегодня существует очень много разработчиков с разным уровнем знаний: есть профессионалы с большим опытом работы и знанием как минимум нескольких языков программирования и культуры разработки, а есть новички с большими амбициями и желанием развиваться.
Не секрет, что PHP считается языком программирования для разработки, на котором необходим минимальный набор знаний. Это язык программирования с очень низким порогом вхождения.
Буквально любой может взять и тут же вывести строку на экран. Именно поэтому опытные разработчики на любых языках программирования считают PHP-разработчиков «ненастоящими» разработчиками, а PHP – «ненастоящим» языком программирования.
Но возможно ли создать на PHP серьёзный продукт и как доказать другим, что PHP можно доверять? Если Вы из тех людей, которые считают PHP «несерьёзным» языком программирования, то советую дочитать до конца и, скорее всего, Вы измените своё мнение.
Разработка любого программного продукта всегда требует нечто большего, чем просто знания самого языка разработки. Для его создания и поддержки разработчику необходимо множество других знаний и навыков.
Мы будем говорить о разработке веб-проекта и о том, что сегодня необходимо знать веб-разработчику для успешного запуска веб-проекта, а главное – я попытаюсь показать, что
Laravel – это идеальное решение для тех, кто хочет быстро и грамотно создать безопасный и надёжный веб-проект, при этом всегда оставаясь на пике технологий веб-разработки.
Начало создания веб-проекта
Прежде чем начать создавать веб-проект, необходимо задуматься не только над структурой проекта и его фишками, но и над процессом разработки и, главное, над своим рабочим окружением.
Сам Laravel хоть и является PHP–фреймворком, но не стоит его недооценивать, ведь это целая экосистема для веб-разработки.
Если Вы скачали фреймворк Laravel в .zip архиве, чтобы оценить его возможности, тогда Ваше рабочее окружение точно настроено неверно, и у Вас существует пробел в знаниях. Вам однозначно стоит внимательно прочитать данную статью до конца.
Этап первый – процесс написания кода
Вы можете работать на любой операционной системе, в том числе и на Windows. Нам необходима хорошая IDE (Интегрированная среда разработки (англ. Integrated Development Environment)) – рекомендую PhpStorm. Можете использовать текстовый редактор Atom или Sublime Text. Конечно, можно писать код и в обычном блокноте, например, Notepad++, но хорошая IDE – незаменимая вещь.
Также после установки IDE или текстового редактора я советую потратить время и изучить как можно больше его возможностей и функций. Это поможет сэкономить массу времени в дальнейшем, а также автоматизировать многие рутинные задачи.
Многие считают, что «крутые» разработчики должны писать код в блокноте, но помнить по памяти названия функций – это одно, а не делать опечатки в коде, упростить и ускорить процесс разработки – это совсем другое. Главная задача – освоить все возможности IDE.
Кроме IDE нам необходимо будет установить Composer, именно через него мы и будем устанавливать (обновлять) Laravel, добавлять (обновлять) дополнительные пакеты в наш веб-проект.
Обязательно изучите работу с Composer, это очень важный и полезный инструмент.
Подробно изучите инструкцию по установке Laravel по этой ссылке.
Далее мы не будем описывать процесс написания кода, а предположим, что Вы уже установили IDE и Laravel.
После установки Laravel в коде сразу прописано отображение базовой страницы – этого достаточно, чтобы перейти к следующей части статьи.
Этап второй – тестирование кода
Для тестирования веб-проекта Вам не надо загружать файлы на FTP-сервер, устанавливать локальный Apache (тот же Denwer или XAMPP) – так делали много лет назад, а многие новички так делают до сих пор. Это неправильно и не спасёт от ошибок в коде. На сегодняшний день для этих задач есть соответствующие инструменты, которые сэкономят много времени и нервов.
Laravel предлагает нам установить Homestead.
Homestead – это образ операционной системы Ubuntu, в которой уже установлено всё необходимое.
С процессом установки и настройки Homestead Вы можете ознакомиться по ссылке.
Для установки образа нам понадобится Vagrant и VirtualBox. Благодаря данному образу Вы точно будете знать, какие модули надо установить и как поведёт себя Ваш код на Ubuntu. Вы также можете установить любой дополнительный софт.
Если кратко, то у Вас в системе появятся общие папки с кодом, которые будут доступны внутри образа Ubuntu, и выполняться Ваш код будет именно внутри Ubuntu.
В браузере Вы набираете site.app, и у Вас отображается сайт из Ubuntu. При этом у Вас также будет доступ к Ubuntu по SSH.
У начинающих установка и настройка Homestead займёт время, но как разработчик Вы просто обязаны это сделать.
Стоит отметить, что Homestead можно установить не только на Linux, но и на Windows.
Далее будем считать, что Homestead установлен, и сайт со свежей версией Laravel открывается у Вас в браузере.
Ваш код запускается в браузере, но действительно ли всё работает?
Ни один уважающий себя разработчик не должен писать код без тестов. Тесты позволяют нам быть точно уверенными, что всё работает так, как мы задумали. Не жалейте времени на написание тестов. Каждый профессиональный разработчик обязательно пишет тесты своего кода.
Laravel предлагает нам инструменты для полноценного тестирования веб-проекта со всех сторон. Вы можете тестировать всё: создать временную базу данных, проверить заполнение HTML-форм, проверить загрузку файлов, даже содержание PHP-сессий и отправку писем.
Laravel создан для качественного тестирования всех возможностей Вашего проекта.
Документацию по тестированию можно найти по этой ссылке.
В Laravel тесты находятся в папке tests и выполняются командой phpunit в консоле, либо сразу из IDE.
Тесты бывают нескольких типов:
- Функциональные – Feature-тесты
- Модульные – Unit-тесты
Feature-тесты – функциональные тесты.
Тесты, которые проверяют функционал веб-проекта, например: регистрацию пользователей, отправку уведомлений, заполнение веб-форм, загрузку файлов. Они позволяют нам проверить, какие именно данные отображаются в браузере. Теперь Вам не надо заполнять веб-формы вручную, чтобы узнать работают ли они.
Также Вы можете проводить тестирование с помощью Laravel Dusk, не просто отправляя HTTP-запросы, а используя реальный движок браузера Chromium.
В этом нам поможет Laravel Dusk.
Unit-тесты – модульные тесты.
Другой тип тестирования называется unit-тестированием. Эти типы тестов проверяют логику нашего приложения, каждую функцию, отлавливают события, определяют отправлено ли письмо, а также сверяют текст письма, проверяют добавлено ли задание в очередь сообщений и всё, что может сломаться, если Вы или кто-то ещё неудачно измените Ваш код.
Каждая функция проекта должна иметь свои тесты, а когда Вы завершите проект, то все тесты должны успешно запускаться.
При изменении функционала Вы можете дописать тесты. Это спасёт Вас и Ваших коллег от ошибок и поможет проще диагностировать проблему.
Unit-тестирование позволяет избежать ошибок в логике приложения.
Стоит отметить, что существует методика разработки TDD (test-driven development) – разработка через тестирование. Сначала мы пишем тесты, а затем постепенно реализуем код. Когда все тесты выполнены, то мы можем сказать, что завершили написание кода.
Если Вы ещё не писали тесты для своих проектов, значит пора переходить на новый уровень. Кроме тестов есть ещё другие помощники для анализа производительности веб-приложения.
Laravel предлагает нам установить Laravel Debugbar.
Это специальный пакет, который отображается на Вашем сайте в режиме отладки. С помощью него можно отследить все SQL-запросы к Вашей базе данных с целью их дальнейшей оптимизации.
Этап третий – сборка проекта
После создания веб-проекта и прохождения тестов нам необходимо подготовить наш проект к размещению на сервере.
Laravel предоставляет нам Laravel Mix.
Laravel Mix использует Webpack и умеет работать с CSS, JS, Less, Saas, Stylus, PostCSS.
Это замечательный инструмент, который, используя специальный сборщик модулей Webpack, собирает вместе все наши JS и CSS-файлы, а также, самое главное, умеет создавать версии этих файлов.
Таким образом, каждая сборка нашего проекта позволяет иметь разные названия JS и CSS-файлов в HTML-коде, что решает проблему с кешированием при изменении содержимого файла.
В шаблоне нашего проекта пишем:
<link rel="stylesheet" href="{{ mix('/css/app.css') }}">После сборки он превращается в:
<link href="/css/app.289df32d2d2c47df3b16.css" rel="stylesheet">При этом браузер посетителя сразу загрузит новый файл с сайта.
Не правда ли, удобно? Точно также и с JS-файлами.
Стоит отметить, что Laravel замечательно работает с прогрессивным Javascript-фреймворком Vue и позволяет очень удобно создавать веб-приложения на базе этого JS-фреймворка. При этом каждый компонент можно удобно размещать в отдельном файле.
О том, как писать компоненты для Vue используя Laravel можно прочитать по этой ссылке.
Этап четвёртый – развёртывание (deploy) кода
Обычно после сборки проекта его файлы необходимо загрузить на сервер и обновить структуру таблиц в базе данных.
Заходим в phpMyAdmin и делаем изменения в БД.
Мы не станем использовать FTP и phpMyAdmin, иначе пока мы вносим изменения, все пользователи, которые зайдут на сайт веб-проекта, увидят множество ошибок об отсутствии каких-то файлов или полей в БД.
Мы можем, конечно, объявить о проведении технических работ, показав нашим пользователям насколько технически сложен наш проект, что требует полного отключения, но никого это точно не обрадует.
Есть очень простое и грамотное решение, которое позволяет обновлять код веб-проекта без его отключения, и ни один пользователь при этом не получит сообщения об ошибке.
Первое что нам необходимо изучить — Git.
Git — это распределённая система управления версиями файлов.
С помощью Git можно отслеживать изменения в файлах, возвращать старую версию файлов и работать в команде над одним и тем же кодом, при этом ничего не перепутав.
Использовать Git можно через сервис.
Вы можете создать либо общедоступный код, либо приватный (для приватных репозиториев – он платный).
Также Вы можете использовать другой бесплатный сервис BitBucket, который позволяет бесплатно создавать приватные репозитории с кодом.
Кроме этого, сам Git можно настроить так, чтобы при внесении изменений происходили определённые действия:
- запуск тестов проекта через Travis CI;
- форматирование кода по стандарту;
- анализ качества кода через инструмент.
Таким образом, весь код Вашего веб-проекта будет храниться в Git, он всегда будет качественный и проверенный.
Например, если Вы предложите внести изменения в официальный код PHP-фреймфорка Laravel, то при внесении изменений автоматически запускаются тесты, которые проверяют работу фреймворка, учитывая новый код.
Ранее мы говорили о процессе развёртывания веб-приложения. Именно для этого нам и необходим Git. С Вашей локальной машины Вы загружаете код веб-приложения в Git, после чего произойдёт автоматический запуск развёртывания приложения на сервере.
Laravel Forge – сервер без хлопот. Для автоматического развёртывания из Git нам поможет сервис Laravel Forge.
Через Laravel Forge Вы можете создать виртуальный сервер в DigitalOcean, Linode или указать доступ к своему собственному серверу. При этом будет настроено абсолютно всё необходимое ПО для работы PHP-фреймворка Laravel.
Laravel Forge автоматически устанавливает обновления, связанные с безопасностью системы. Также Forge легко установит бесплатный SSL-сертификат от Let's Encrypt.
Вы можете дать сервису Laravel Forge доступ к Вашему Git-репозиторию и при каждом изменении в коде на сервере будет автоматически развёрнута его свежая версия.
Хотите 10 серверов? – Без проблем, Laravel Forge может установить балансировщик нагрузки, создать 10 виртуальных серверов, на каждый сервер копировать код из Git и запустить проект.
Думаете всё?
Нет, совместно с Envoyer Вы можете запускать новый код в работу без остановки сервиса совсем.
Хотя лично я не использую Envoyer, а просто написал небольшой скрипт в панели Laravel Forge, который запускается при каждом развёртывании кода и обеспечивает замену на лету, при этом сохраняя ещё несколько копий старого кода на самом сервере.
> Ссылка на скрипт
Итоги
Мы создали комфортное рабочее окружение, установили IDE, Composer, PHP-фреймворк Laravel, написали код проекта, запустили тесты, изучили систему контроля версий Git, отправили туда код, подключили сервис Laravel Forge, при желании подключили также Laravel Envoyer, сделали развёртывание проекта на рабочий сервер из нашего Git-репозитория.
Можно сказать, что Laravel направил нас на грамотный путь в веб-разработке. Впереди ещё многое предстоит изучить, но мы уже проделали большую работу и можем начинать работать в команде с другими разработчиками.
Основные возможности PHP-фреймворка Laravel
А теперь рассмотрим возможности самого PHP-фреймворка Laravel: какие веб-приложения позволяет нам создавать данный PHP-фреймворк, насколько он продвинутый в техническом плане и почему он так популярен во всём мире.
После выхода PHP7 по сравнению с PHP5, скрипты стали быстрее и начали использовать гораздо меньше оперативной памяти, а в связке с Zend OPCache показывают замечательные результаты. В частности сервис Laravel Forge настраивает Zend OPCache для достижения максимальной производительности.
Именно поэтому, когда идёт речь о производительности того или иного PHP-фреймворка, то всегда проводят тестирование без кеширования, работы с БД или файлами, в основном совершая множество вызовов к обычной PHP странице. В этом плане данный PHP-фреймворк существенно ничем не отличается от всех остальных, но когда речь идёт о масштабируемости, гибкости, универсальности встроенных механизмов кеширования и скорости разработки, именно тогда Laravel показывает всю свою гибкость и мощь.
Сам Laravel постоянно совершенствуется и следует современным тенденциям. Изучая его, Вы не отстанете от мира веб-разработки, главное – не зацикливаться на какой-то конкретной версии фреймворка, а развиваться вместе с ним. Для этого необходимо также изучать нововведения Laravel.
Ежегодно проводятся различные конференции, которые можно посмотреть также и онлайн.
Постараюсь описать основные возможности Laravel, чтобы можно было оценить масштаб:
- MVC (англ. Model View Controller – модель-представление-контроллер) PHP-фреймворк построен на базе известных и надёжных компонентов Symfony.
- Необходимые модули для фреймворка подключаются в виде пакетов-провайдеров (service provider). В версии Laravel 5.5 достаточно просто установить пакет через Сomposer, и он сразу будет доступен, без необходимости что-либо писать в коде.
- Код фреймворка отделён от кода разработчика, каждый компонент легко расширяется.
- Код веб-проекта, CSS, JS, HTML-код страниц разделены в отдельные директории. Фреймворк использует замечательный шаблонизатор Blade, который позволяет отделить вёрстку от PHP-кода. Сам шаблонизатор настолько прост, что даже начинающий HTML-верстальщик сможет легко его осилить.
- Удобная маршрутизация, валидация входящих параметров.
- Кеширование, работа с хранилищами файлов, работа с различными БД.
- Миграции для базы данных, Вы можете изменять структуру БД и откатывать изменения.
- Очереди заданий, планировщик задач, консоль, работа с SSH.
- Огромный функционал Eloquent ORM позволяет полностью обезопасить себя от атак типа SQL Injection, а также загружать данные из нескольких таблиц (решая проблему N+1) или же обрабатывать данные из БД частями.
- Laravel Collections – можно сказать, что это PHP массивы, но с очень продвинутыми возможностями, которые экономят массу времени.
- Кэширование файлов маршрутизации, файлов конфигурации, шаблонов. Это ускоряет работу фреймворка.
- Отправка уведомлений различными способами: почта, Slack и т.д., можете дописать сами.
- Поддержка WebSockets для создания настоящих интерактивных приложений.
- Поддержка мультиязычности: легко добавляйте любые языки, а пакет Laravel-lang уже содержит множество переводов.
- Интерфейс командной строки artisan, который позволяет генерировать модели, контроллеры, уведомления, запускать задания из очереди заданий и многое другое.
- Laravel Tinker – дополнительный пакет, который позволяет работать с кодом проекта из командной строки.
- Огромные возможности для тестирования веб-проекта, включая заполнение базы данных тестовыми данными.
- У фреймворка есть даже собственный сайт с библиотекой пакетов.
- Нужен полнотекстовый поиск? Пожалуйста – Laravel Scout, можно использовать Algolia, Sphinx и другие драйвера.
Впечатляет, не правда ли? А я не описал даже и половины возможностей.
С помощью Laravel можно одной командой сгенерировать систему регистрации и входа на сайт и с лёгкостью подключить сервисы OAuth аутентификации благодаря Laravel Socialite или даже создать свой с помощью Laravel Passport.
Для тех, кто не знает OAuth, – это возможность войти на сайт через социальные сети.
Это лишь малая часть того, что умеет Laravel, и если начинающий PHP-разработчик изучит его возможности, даже не углубляясь в ядро самого PHP-фреймворка, то это безусловно поднимет его уровень знаний не только в разработке на Laravel, а в веб-разработке в частности, включая навыки работы в команде и понимание принципов разработки высоконагруженных проектов.
На основном сайте PHP-фреймворка Laravel недаром присутствует девиз:
«Любите красивый код? Мы тоже. PHP-фреймворк для веб-мастеров.»
Ведь код PHP-фреймворка Laravel не только красивый, приятно читаемый, но ещё и очень грамотно продуман, а над любым изменением думает множество людей, что позволяет создавать профессиональные веб-приложения на уровне мастера своего дела.
Полезные ссылки:
Сайт PHP-фреймворка Laravel.
Основные новости PHP-фреймворка и новости о различных пакетах.
Laravel на русском и русскоязычное сообщество Laravel в VK.
Очень рекомендую сайт https://laracasts.com, где Jeffrey Way в своих видео-уроках наглядно и без лишних слов показывает возможности Laravel, также рассказывает много полезных вещей. За 2 минуты человек успевает рассказать больше и доступнее, чем многие за час.
А также рекомендую книгу "Refactoring to Collections", где Adam Wathan подробно рассказывает о возможностях Laravel Collections. Гарантирую, Ваш код изменится в лучшую сторону.
Рекомендую в каждый веб-проект на Laravel устанавливать:
P.S.: Данная статья получилась довольно объёмной и без технических подробностей, но её основная задача – дать начинающим разработчикам вводные знания, объяснить что же такое Laravel и какие возможности он даёт, а также показать, что Laravel – это не просто PHP-фреймворк, а целая экосистема, которая постоянно развивается. Это именно тот тренд, на который должны обратить внимание PHP-разработчики.
Многие вещи могут быть непонятны для начинающих, но не стоит отчаиваться. Любой термин достаточно быстро можно найти в сети. Я лишь попытался обобщить информацию именно в том порядке, в котором должен её воспринимать начинающий разработчик.
Если Вам понравилась статья, то буду уже подробнее писать про каждый этап в данной статье с техническими деталями и кодом.
Комментарии (104)
zugo
03.08.2017 15:48-2Вроде и хорош Laravel на первый взгляд, но, по факту, для более-менее серьезного использования он годится только после доработки стандартного сетапа и нарушения всего, что говорит документация и предлагают авторы.
В ларавеле можно использовать инъекцию зависимостей по интерфейсу, заменить ущербный Eloquent на Doctrine (или вообще обойтись без готовой ORM), можно запилить структуру проекта согласно принципам «гексагональной архитектуры» или DDD, да и вообще много чего можно сделать.
Но, по факту, официальная документация и туториалы предлагает вместо этого использовать статические фасады для доступа к чему угодно (начиная с 5 версии — так и вообще просто глобальные функции типа app(), dispatch() и т.д. Забавно, что сам Тейлор аргументирует тем, что, мол, «под капотом» фасадов и функций на самом-то деле DI-контейнер инстанцирует объекты, как будто это что-то меняет)
Макаки, разумеется, в восторге — можно говнокодить безо всяких ограничений не включая мозг. Напрямую обратиться к БД в темплейте? Легко! Вызвать какой-либо сервис прямо из модели? Запросто! И именно поэтому ларавел так популярен! На западе уже, фактически, это «новый вордпресс». Да, казалось бы, дело в макаках, а не в ларавеле, но почему тогда документация учит «плохим» практикам, даже толком не упоминая о «хороших»?
А про «экосистему» и говорить не хочется — с каких пор привязка к вендорским инструментам стала благом?SwVZFSf4fLt8NSZNfV87 Автор
03.08.2017 18:07+3Низкий порог вхождения во фреймворк, также, как и в PHP не значит, что он плохой.
Фреймворк позволяет нам ускорить процесс разработки и имеет очень обширный готовый функционал, не говоря уже о дополнительных пакетах.
Чтобы полностью создать веб-проект, необходимо знать множество вещей, не только PHP.
Почему начинающие пишут код в шаблоне? Потому что им кажется, что так проще.
Просто люди не знают как правильно, им никто этого не объяснил, именно для этого и существуют обучающие материалы.
Проблема в том, что все знания необходимо собирать из разных источников, их надо искать.
А как найти то, не зная что искать?
В статье я попытался рассказать, что именно необходимо искать и в каком порядке.
Безусловно, опытному разработчику мягко говоря неудобно поддерживать код, который писал начинающий, хочется взять всё и переписать, но виноват в этом заказчик.
Именно заказчик и обязан проверять квалификацию исполнителя, но зачастую заказчику важна стоимость разработки, а не качество и красота кода.
А грамотных заказчиков столько же, сколько и грамотных исполнителей — мало.
Фреймворк очень быстро развивается, улучшается всё, в том числе и документация.
Как писать чистый и понятный код? Только опыт, общение с другими разработчиками, участие в Open Source проектах.
Попробуйте реализовать проект именно так, как рекомендует документация, посмотрите другие похожие проекты на Laravel и следуйте их практикам.
Главное, не пытайтесь всё переделать, в 99% люди уже решали те же задачи. Зачем изобретать велосипед.
Мы все стараемся всё усложнять, а необходимо упрощать. Самое трудное сделать из сложного — простое.
Технологии развиваются, люди думают как лучше, как проще, появляются новые практики.
Кто-то скажет давайте напишем на asm веб-сервер, сегодня покрутят у виска, а 20 лет назад сказали бы да, давайте.
Laravel — это возможности. Это красивый код, если хотеть писать его красиво и да, этому надо учиться. До сих пор все спорят: табуляция или пробел =)
Посмотрите книгу «Refactoring to Collections», разве это неудобно? Collections
Сам фреймворк решает именно необходимые задачи, которые возникают у всех проектов.
Тот же IoC и Eloquent удобен, если решаешь его использовать.
Конечно, что-то сделать нельзя, но для этого и есть открытое сообщество, предлагайте идеи, ведь все хотят сделать лучше и удобнее.
Но мы то как привыкли — что-то не получается, тут же говорим, что фигня и возвращаемся к старому.
А если посмотреть с другой стороны, например, Вы хотите создать стартап.
- Вы быстро можете создать то, что необходимо. Создание кода, тестирование, деплой.
- Быстро запустить проект в работу, а с помощью сторонних вендоров ускорить весь процесс и качество кода.
- Быстро развернуть проект с балансировкой нагрузки в случае необходимости.
- Laravel Forge, например, экономит время при настройке сервера, не хотите платить, так или иначе Ваше время = деньги.
- Обновился фреймворк — легко обновляете, есть список изменений и инструкция по обновлению, если следовали общей практике, то вообще всё просто.
- Любой Laravel разработчик сможет разобраться в коде проекта.
Что Вы как владелец стартапа предпочтёте?
Нанимать PHP-разработчика и создавать свой функционал с нуля и надеяться, что стартап взлетит и другой разработчик в случае чего сможет в нём быстро разобраться.
Или же нанять Laravel-разработчика, который реализует то же самое, но дешевле, и Вы точно знаете, что можно найти ещё разработчика на Laravel, который легко разберётся в коде проекта.
И это всё при том, что стартапов как грибов. HH и в продашкн, как говорится, но если хотите грамотно и быстро, то Laravel даёт возможность это всё сделать.
Конечно, ни одному человеку неприятно осознавать, что он легко заменяем, НО грамотный разработчик всегда останется грамотным и такая у нас профессия — постоянно надо учиться.
Если Вы НЕ успеете запрыгнуть в этот поезд, где надо делать всё быстрее и дешевле, используя как преимущество свой опыт, то может случиться так, что Вы будете предлагать заказчику реализовать форму авторизации, регистрации и восстановления пароля на сайте за 2 недели, когда это всё делается одной командой: php artisan make:auth.
Конечно, обсуждать можно долго, аргументов множество, книжку можно написать.
Кому-то нравится, кому-то нет, но, безусловно, стоит обратить внимание и потратить время.
Когда-то я вообще думал, что мне не нужен фреймворк, я сам могу реализовать с нуля всё, что мне надо, но есть ньюанс — время, за него никто не хочет платить.
Информации сегодня настолько много, что её необходимо фильтровать, не то что читать, иначе жизни не хватит всё изучить и самое главное, не знаешь что тебе пригодится.
Именно поэтому начинающим и необходим какой-то план по изучению, а не крупицы из разных источников и чем проще будет подана информация, тем легче её осознать, а дальше уже приходит опыт и желание сделать код красивым.
Экосистема — позволяет не просто написать код и кинуть на FTP, а создать проект, тестировать, поддерживать. Люди решают те задачи, которые необходимы.
Никто не заставляет использовать какой-либо язык разработки или фреймворк: просто кто-то хочет использовать новые технологии, а кто-то нет.zugo
03.08.2017 18:32-5Дайте угадаю, Вы — евангелист Ларавела и вам за это платят?
Вы рекомендуете читать документацию, и следовать практикам, принятым в ларавел-сообществе, а я уже упомнянул, что документация и сообщество как раз таки поощряют писать говнокод, не рассказывая о том, что возможен другой путь (enterprise-like практики).
Хотя, конечно, для типового веб-приложения (== пачки примитивных крудов) этого более чем достаточно, и скорость разработки куда важнее. А до поддержки и наращивания функционала, скорее всего, даже и не дойдет — редкий мегасовременный хипстерский стартап живет больше года.
SerafimArts
03.08.2017 19:06+3что документация и сообщество как раз таки поощряют писать говнокод
В документации указан самый простой вариант для использования. Если он не подходит по какой-то причине — давайте уже сами, это не CMS, где только кнопочки нажимать, тут ещё и думать надо.
И да, отвечайте за себя, пожалуйста. За всех не говорите, ок?
SwVZFSf4fLt8NSZNfV87 Автор
03.08.2017 19:48+3Мне просто нравится Laravel и я решил помочь начинающим разработчикам на Laravel.
В поддержку enterprise — есть LTS релизы. Но фреймворк очень активно развивается и в каждой версии добавляется что-то хорошее.
Если мы говорим о балансировке нагрузки, работе нескольких разработчиков над проектом, то всё есть.
Я понимаю о чём Вы говорите, DevOps, QA, банковский сектор и т.д.
Документация позволяет изучить сам фреймворк, базовые возможности, что-то дополнительно, а как применять PHP в enterprise — это отдельная тема, точнее книга и не одна.
И давайте откровенно, на вскидку, проект с 30к онлайн фреймворк выдержит без особых сложностей, кластеров БД и т.д. Есть кеширование, балансировка, CDN, очереди, да всё есть.
Задача — просто грамотно спроектировать проект, а это выходит за рамки документации по фреймворку.
У большинства проектов если есть 30к за сутки, то можно считать стартап успешным.
А что такое пачка примитивных крудов? Весь интернет, не считая монстров типа google, — пачка примитивных крудов.
Я лично поддерживаю новостной проект на DLE с посещаемостью от 30к до 100к посетителей в сутки.
И никакой фреймворк тут вообще ни причём, только nginx с SSI кеширует всё грамотно, ещё и сам DLE пришлось модифицировать.
Вы можете представить чтобы DLE из коробки выдерживал нагрузку с пользователями и забивал канал в 3гбит? Там до сих пор apache mod_php.
Посмотрите конференции по Laravel, TDD и т.д. Мне кажется, это всё знания, которые невозможно сжато уложить в документацию к PHP-фреймворку.zugo
03.08.2017 20:24+3Я прекрасно понимаю, как можно использовать фреймворк в ынтырпрайз-стиле. Я говорю о том, что ни документация, ни сообщество, ни стартовая структура директорий, к этому совершенно не поощряют.
Придет новичок-вчерашний сайтошлеп, который не слышал про SOLID, GRASP, сервисы, интерфейсы и прочие умные слова (а мы почти все такими были когда-то), и увидит ваши статические вызовы чего угодно откуда угодно, и подумает, что так и надо делать. Да, быдлокод на чем угодно можно писать, но ларавел к этому просто подталкивает.
Весь интернет, не считая монстров типа google, — пачка примитивных крудов.
Я говорю о всяких там SaaS, ERP-системах и прочем. Там бывает, что бизнес-логика не укладывается в модель крудов, изредка даже головой приходится подумать. Нравится нам это или нет, но PHP уже давно на полном серьезе пришел в enterprise-разработку.
Helldar
04.08.2017 01:48Вспомнилась жизненная шутка:
Написал программист код: «ну, код как код».
Вернулся к нему на следующий «день: всё нормально».
Вернулся через неделю: «блин, что же делает этот метод?»
Вернулся через год: «руки б оторвать тому кто это всё писал»
Так и в ситуации каждого из разработчиков, когда с каждой строчкой кода приобретаем новый опыт.
Опыт приходит с опытом, как говорится. Так что сетовать на якобы «неадекватность» документации не надо — там всё просто и понятно написано. Разработчик, в первую очередь, работает головой, либо учится этому в доках да узкоспециализированных чатах.
ЗЫ: А, разве, по-вашему, на нативном пыхе или других фреймах не говнокодят?
WebArtisan
03.08.2017 20:15+2Забавно, что сам Тейлор аргументирует тем, что, мол, «под капотом» фасадов и функций на самом-то деле DI-контейнер инстанцирует объекты, как будто это что-то меняет
То что вы не видите разнцицу между статистическими вызовами и фасадами, это не говорит, о том, что это ничего не меняет. И если бы вы капнули поглубже документация рекомендует программирование по контрактам, предпочтительнее использования фасадов.
что документация и сообщество как раз таки поощряют писать говнокод
Когда мне начинают рассказывать, что на Laravel говнокодят, что Eloquent нарушает принцип единой ответственности и показывают тру «enterprise-like практики»(что бы это ни были в вашем понимании), аля отделение репозитория от модели и показывают количество кода для создания простой записи в базе со связями… Что толку от ваших «enterprise-like практик» и строгого следования тем же SOLID принципам, если на Laravel я реализую ту же логику в разы изящнее и в нескольких строках кода, в отличии от десятка строк на том же Symfony. Что наоборот делает код более поддерживаемым и понятным.
Люди забывают, что все эти принципы и практики, придуманы для того, что бы упрощать код, а не просто им следовать.zugo
03.08.2017 20:35-2То что вы не видите разнцицу между статистическими вызовами и фасадами, это не говорит, о том, что это ничего не меняет.
Ну так просветите, что это меняет для меня, как пользователя фреймворка? Фасады, пожалуй, даже хуже — работают на «магии» (помню, сильно удивился, когда в первый раз перешел к определению «фасадного» метода) и даже для автокомплита в IDE требуют костылей.
Когда мне начинают рассказывать, что на Laravel говнокодят, что Eloquent нарушает принцип единой ответственности и показывают тру «enterprise-like практики»
Вы, видно, не писали более-менее больших проектов с сотней хитрожопо взаимосвязанных сущностей. Да даже без этого — «чистая» модель как сущность бизнес-логики гораздо удобнее, чем ActiveRecord с магическими свойствами. Не говоря уж о том, что, даже безотносительно SRP, как правило таблица БД не полностью идентична сущности бизнес-процесса (за исключением самых простых случаев).
VolCh
04.08.2017 09:38+2В том-то и дело, что enterprise-like практики не предназначены для CRUD-оперирования простыми табличками. Банальный трехшаговый мастер заполнения формы сущности уже плохо ложится на CRUD, а уж если это процесс, в котором задействовано несколько человек, программных агентов, сущностей, подпроцессов и т. п., то ActiveRecord не то, что не помогает, а начинает мешать. А такие процессы давно уже достояние обычных приложений. Банальная регистрация пользователя с привязкой банковской карты или ручным апрувом менеджером уже плохо сводится с CRUD над простой табличкой, а представляет собой процесс с несколькими участниками, растянутый по времени.
michael_vostrikov
04.08.2017 11:08Фасады в Laravel это примерно то же самое, что и Service Locator.
DB::something()иYii::$app->db->something(). Только с переменными можно просто сделатьYii::$app->db2, а с фасадами надо выкручиваться черезDB::connection('db2'). И выглядит нелогично, вроде вызов статический, а меняет состояние.
AndyPike
03.08.2017 21:50Нанимать PHP-разработчика и создавать свой функционал с89 нуля и надеяться, что стартап взлетит и другой разработчик в случае чего сможет в нём быстро разобраться
Вот и получается у мигрирующих разработчиков тут у на с 2 касты, точнее три (первая не в счёт)
1. Я хозяин, модно, давайте всё ломать и строить заново. Просто модно.
2. Product Manager или Team Leader — давайте подумаем. Т.к. им надо принимать решение о выборе фреймворка под задачу. Потянет или нет? Платформы, удобства для Linux/Windows пользователей в команде.
3. TL набирает команду под проект. Если уже знаешь — почти всегда пройдёшь. Не знаешь — учись, сейчас это модно, всего полгода (и много разной шелухи), и сможешь стать джуном нашего проекта.
У меня религия, наверное, не позволяет использовать перегруженные фреймворки в простых задачах.
Может, я работаю именно с такими.VolCh
04.08.2017 09:49+1Ну, насчёт полгода и джуна — передергивание. У меня в бэкграунде за последний десяток лет только Symfony на задачах больше месяца, но конкретные офферы дают на позиции Senior, TechLead, Architect на постоянку на проекты и на Laravel, и на Yii, и на Zend. Не видит серьёзный бизнес проблемы в том, что пару-тройку месяцев человек будет изучать новую для себя экосистему и за это бизнес готов платить порядка десяти тысяч.
BrainExploded
04.08.2017 16:13+1Ларавель — хороший фреймворк, удобный и передовой, соглашусь. Но мне больше нравится Yii, наверное, потому что в нём я каждую дырку знаю, и мне он ближе по духу. Щас, правда, проект на ларавеле. Хорошо, но то и дело не хватает Yii. Каждый раз я сначала мыслю, как бы я это сделал «там», а потом придумываю, как это перевести на лару.
А теперь разрешите вставить пару (на самом деле, нет) слов о стилистике текста и об идеологии, которая в нём заключена:
Пожар на тему манагерских штампов и оголтелости заявленийНесказанно жрёт мозг помешательство последних лет среди программистов ПХП на моде, тенденциях, на скидывании всего и вся с «корабля современности» и на «запрыгиваниях в поезд прогресса». Нет, я не ретроград по отношению к технологиям — новые технологии и подходы я горячо приветствую и любовно изучаю. Именно из-за того, что в программировании всегда есть свежий воздух я и тут! Но — не тенденции, не мода, не ломка старого тут рулят. За слово «мода» и за словосочетание «надо следовать тенденциям» я бы сажал на кол: жестоко, но так приятно в шутку об этом подумать.
Надо вкладываться в долгосрочные перспективы, а не сиюминутные веяния. Развиваться, а не ловить хайпы. Пока все, как нервно-поражённые истерички бегают тесной толпой то на руби, то на шарп, то на ноду и js, надо изучать алгоритмы, подходы и набирать опыт. Тихо, не особо спеша, медленно, но верно, успевая, при этом, заняться ещё и другими делами и увлечениями. Не пренебрегая старым — ведь качество продукта зависит не от фреймворка по большей части и не от языка даже, а от программиста. Эти хипстеры уйдут к чёрту из профессии, как только оно станет не модным или когда средняя ЗП поползёт вниз, вот тут-то вы и пригодитесь втройне. Да, я своими глазами видел, как непонятно откуда взявшийся человек запилил отличного демона для наших нужд на делфи, Карл! Я ненавижу делфи, но факт есть факт. Демон работает бесподобно, выполняет свои функции, и при этом, человек, его написавший, реализовал свой интерес — программирование на любимом ему языке.
Теперь про asm — ну, в коммерческом проекте, не связанном с железом и чипами никто и не будет писать на асме, а если интересно для собственного развития и интереса — можно запилить и веб-сервер. Всё польза. Ну, если времени у вас дохрена. Но вот на Си — пожалуйста — куча работы: низкий уровень, железо, что-то, что требует большой скорости, драйвера, движки и т.д — дерзайте. Я лично обожаю Си, и считаю, что он никогда не умрёт.
Про поезд: мне кажется, увы, с момента, когда я увлёкся программированием — а было это очень давно — система ценностей и взгляды в комьюнити (по крайней мере, русском) сильно поменялись. Если тогда, я помню, главным было качество кода, знания, страсть к профессии и вечное, типа актуальных всегда подходов, базовых знаний и умений, а щас всё упирается в рынок, моду, ноду и тенденции на языки. Никто не боится говнокодить, бегать по верхушечкам и кричать что-то про корабль современности более флегматичным людям, зато до смерти боятся «опоздать на поезд», «отстать» от моды, до сих пор сидеть на «древнем питоне», вместо прекрасной ультрамодной ноды, и так далее. При всём при этом, я нода и современный js — прекрасны по моему мнению, читаю материалы по ним, но от этой нервной риторики «скорее, скорее, опоздаем!!» уже так сильно тошнит, что хочется кому-нибудь врезать!
А в итоге-то — что там успевать? Если ты не работаешь на проекте, где тебя круглые сутки заваливают текучкой — ты в состоянии хотя бы раз-два в неделю освоить новую статью, новую либу или пошерстить на гитхабе, покопаться в чужом коде, почитать книжку часок и повелосипедить, не в ущерб свободному времени. А значит, ты успеваешь на этот самый «поезд», не нарушая свою и чужую психику. Если такой возможности нет, и ты сидишь, тянешь воз с 10 утра до 11 ночи — значит, что-то пошло не так: или берите ещё людей в штат, или увольняйтесь. Это просто решить.
Так что, фреймворк, язык, библиотеки — это чистая вкусовщина. Поверьте, не сильно они все отличаются, любой опытный адепт любого языка и фреймворка справится с задачами примерно одинаково, если это не что-то совсем уж специальное, подо что есть специальные языки. И гнобить людей за «неправильный выбор» фреймворка\языка — последнее дело.
Теперь про простоту: мой зад потихоньку поджаривается, как только я это слышу. Потому, что этот лозунг — любимая отмаза всех халявщиков, случайных людей, пришедших в программирование из-за ЗП и простоты трудоустройства. «Почему написал логику во вьюхе? Какого хрена ты скопипастил код, по что у тебя весь код в синглтонах, а в них всё залито толстым слоем хардкода?» Ответ один: «Так проще, упрощай, велели нам статьи на хабре» А написать лишние строк 100, зато правильно — это типа уже не тру. Моя кровь закипает. Каждый, кто пришёл в программирование из страсти к кодингу и разработке упрощает только тогда, когда это полезно и удобно ему, а не из принципа (из принципа можно и переменные a,b,c называть для краткости). Вот адепты с++ или джавы, к примеру, совершенно не обламываются писать длинные синтаксические конструкции, они привыкли, и хорошо в них ориентируются, значит ли это, что они хуже питонистов? Вот ни разу, они тоже заворачивают всё в либы, и применяют передовые подходы.
Извините, накопилось)SerafimArts
04.08.2017 16:20Каждый раз я сначала мыслю, как бы я это сделал «там», а потом придумываю, как это перевести на лару.
Это проблема всех Yii'шников, которые переходят на любой другой нормальный фрейм. И это не было бы проблемой (например, используя Laravel можно использовать подходы Symfony, Zend или какой-нибудь Spring смело, и наоборот), если бы в Yii было бы сделано что-то грамотно, но увы.
BrainExploded
04.08.2017 16:31Было два проекта больших на Yii, вот как раз там было всё очень удобно и прозрачно. Будь Yii плохим фреймворком — не снискал бы столько лучей обожания ото многих людей. И вообще, понятие «нормальный фрейм» — очень субъективное. Для яичников — это yii, для симфонистов — симфони, очевидно. Было бы лучше, если бы люди не делали радикальных заявлений относительно того, что богу подобно, а что плохо, да ещё и менторским тоном и безапелляционно.
Тем более, что особо разницы я не почувствовал, на вкатывание после yii мне понадобилась одна неделя сразу после устройства на новую работу.SerafimArts
04.08.2017 20:10+1А никто не говорит, что Yii не выполняет свою задачу. Выполняет. Только почти что каждую задачу можно решить проще и элегантнее с перспективами на вырост. В случае Yii этого не получится. Зато то, что умеет Yii — делает быстрее всех. Ну, примерно как JQuery среди React, Angular, Vue и прочих.
Если учитывать это, то утверждение "не надо переносить подходы Yii на другие фреймы" становится чуть менее радикальным, верно?
BrainExploded
04.08.2017 21:35Теперь согласен. Йи не дружит с общепринятыми практиками, но удобен как чёрт. Впрочем, всё равно нужно будет писать прослойку сервисов\компонентов для логики (чтобы не сувать её в контроллеры и модели), и с этой точки зрения лично для меня разница небольшая — DI в ларавеле или синглтон Yii::. Привычному к yii человеку делать это всё так же, как привычному к sf на этом sf.
Может, я и не прав, но для тех задач, что у меня были — шо то, шо то, просто чуть разные подходы. Будь я евангелистом паттернов (вот чтоб прям не отходить от них никогда), я б бугуртил, конечно.SerafimArts
04.08.2017 21:47Угу, на Yii клепать бложики одно удовольствие, захреначил круд, гриды и вперёд. У ларки в этом случае надо чуть подумать, круд фигачится не одной, а двумя командами, вёрстку тоже сам, но зато этот сайт может через год запросто превратиться в реактивный самолёт, а от кода можно получать эстетический оргазм, которым даже Symfony не может похвастаться: Laravel vs Symfony (как минимум по той причине, что в симфони почти невозможно избавиться от сервис локации в контроллерах)
zugo
04.08.2017 22:22в симфони почти невозможно избавиться от сервис локации в контроллерах
Неправда. А с версии 3.3 DI стал еще удобнее.SerafimArts
04.08.2017 22:33Покажите мне как заинджектить такую шляпу в сервис и считайте, что убедили, что DI у симфони невероятно крутой. Я обещаю молчать в тряпочку.
class MyService { public function getUsersFromDatabase(UserRepositoryInterface $users) { dump($users); // DoctrineRepository } public function getUsersFromFile(UserRepositoryInterface $users) { dump($users); // FileRepository } }
+)
P.S. Подсказка: Кажется это не DI, а надстройка над методами контроллеров (раньше по крайней мере так было, парам резолвер, если не путаю).
zugo
04.08.2017 22:49Сейчас можно инъектить в конструктор, в сеттер, в свойство. Инъекция в геттер была запланирована, но от нее отказались.
Вы можете привести пример, где без этого действительно нельзя было бы обойтись и не хватило бы, скажем, инъекции в конструктор?
И я, кстати, не утверждал, что в Symfony DI лучше, чем в Laravel. Речь вообще шла не о возможностях фреймворков, а о практиках, принятых в том или ином сообществе.SerafimArts
04.08.2017 23:51Вы можете привести пример, где без этого действительно нельзя было бы обойтись и не хватило бы, скажем, инъекции в конструктор?
Например сервис, отвечающий за предоставление доступа к внешнему ресурсу (например какой-нибудь синхронизатор данных БД и внешнего источника):
interface SomeServiceSyncrionyser { public function __construct(HttpClient $client); public function get(string $uri, ...): void; }
Который, например, должен легко расширяться и патчиться. Естественно ресурс в каждом методе будет требовать какие-то внешние зависимости, например репу пользователей для синхронизации пользователей или репу артиклов, для синхронизации статей.
Вариантов можно очень много придумать где нужна двойная диспатчеризация.
Да что далеко ходить, до недавнего времени не было даже инъекций в методы контроллера, все говорили делай инъекции в конструктор, а потом это всё превращалось либо в километр аргументов в оном, либо чувак забивал и вхреначивал весь контейнер (trait ContainerAware до сих пор через сеттер это делает), либо самые умные сквозь реквест это пробрасывали.
Я к тому, что бывает нужно, на практике столкнулся с таким и кроме фигачивания фектори от фектори (sic!) варианта не оказалось сделать удобно =\
zugo
05.08.2017 00:04Ну здесь как раз можно вспомнить про принцип единственной ответственности. Если в конструкторе слишком много аргументов — то явно что-то не так, и, может быть, стоит разделить серивис на несколько?
SerafimArts
05.08.2017 00:34Сервис отвечает за работу с пользователями, методы:
1) Синхронизировать список: Требует репу юзеров + конфиги юзеров
2) Синхронизировать текщего: Требует репу юзеров + инфу о текущем аутентифцированном + конфиги юзеров
3) Синхронизировать N: Репа + конфиги юзеров + сторонний юзер
4) И ещё можно тучу придумать.
BrainExploded
06.08.2017 21:43+2клепал на Yii не бложики, и не только круды — и претензий особых не имел, всё и взлетало, и неплохо летело, так что, я, всё-же, продолжу стоять на том, что это всё — просто вкусовщина. Мне вот нравится он и всё, а там уж что где чуть удобнее или чуть элегантнее — вопрос интересный, но не фатальный.
Я не посягаю на вашу любовь к ларавелю, просто увеличиваю присутствие любителей других фреймов в данном треде. Вот любители Ларавеля очень агрессивно зачастую пытаются доказать, что yii не нужон, и что «только лв», некоторые откровенно окатывают говном из ушата его сторонников, заявляя, что на всё сообщество там пять нормальных программистов (в другом треде), ещё один писал статью, что не сладил с yii, и для него он превратился в ад. Забавно это всё. Я же не говорю таких вещей, просто — мне норм, у меня всё на нём получается. В том числе и в проектах, выходящих за рамки крудоты и бложиков.
BrainExploded
04.08.2017 16:48хотя, может ты и прав, может быть лара и универсальнее с точки зрения подходов других фреймворков. Впрочем, yii от этого хуже не стал. Пусть и вещь в себе, но это не ярко выражено. Вот ни разу не было такого, чтобы пришлось там материться на сам фрейм.)
voidshah
05.08.2017 00:40)) У меня наоборот. Пишу на Yii последнее время и много. И все время думаю, что сделать это на ларе было бы куда проще, элегантнее ))
franzose
05.08.2017 02:36Я вам больше скажу: Laravel поднялся за счёт хайпа и агрессивного маркетинга. До третьей версии об этом фреймворке мало что было слышно. Тем не менее мне самому он, в принципе, нравится. Многие вещи сделаны довольно «сахарно».
AmdY
03.08.2017 20:36-1Доработка сетапа нужна везде, но именно в laravel и yii она требуется меньше, так как фреймворк из коробки содержит кучу приятныхз фишек, о чём собственно и статья. Когда ты садишься работать за симфони после ларочки, то чувствует себя вообще голым, разве что визитки с таким сетапом разрабатывать, нет очередей, редиса и т.д.
Про DDD и гексогоналку. Мне казалось, что суть этих технологий как раз в отсутствии привязки к стораджам и всяким eloquent или doctrine. Мне кажется вторая даже вреднее, так как люди тешат себя иллюзией о правильной архитектуре, а по сути вместо спагетти кода пишут лазанью.
Про документацию вы правы, там примеры демонстрируют ТОЛЬКО конкретный инструмент и не связаны друг с другом. Но так везде, в доке по php даже есть приписка про этот момент. Но есть laracast демонстрирующий хорошие практики. В доке был ещё пример полноценного приложения, но его найти не могу.
Ну а в остальном ваши придирки субьективны и зависят от разработчика. У меня за спиной десяток проектов с laravel и пяток с symfony, в ларавеле ниже порог входа и куча говнокода от авторов не осилевших доку до конца, в симфони же беспощадная слоёная архитектура от авторов не осилевших php и в поддержке они на порядок сложнее, даже хуже битрикса.zugo
03.08.2017 20:48+1Про DDD и гексогоналку. Мне казалось, что суть этих технологий как раз в отсутствии привязки к стораджам и всяким eloquent или doctrine. Мне кажется вторая даже вреднее, так как люди тешат себя иллюзией о правильной архитектуре, а по сути вместо спагетти кода пишут лазанью.
Безусловно Вы правы, но Doctrine (если использовать ее правильно) — это единственная ORM на PHP, которая позволяет приблизиться к принципу persistence ignorance. В конечном счете, для доменного слоя репозиторий — это только интерфейс, и его может в инфраструктурном слое имплементировать класс, наследующий в то же время EntityRepository. В случае же с другими ORM придется вручную «пересыпать» данные внутри репозитория в доменную сущность.
Но есть laracast демонстрирующий хорошие практики.
Помню, долго смеялся, когда автор ларакаст запилил курс с примерами по DDD в ларавеле. Команды у него в себе носили модели, а репозиторий возвращал экземпляр Eloquent'а. Называется — «слышал звон, да не знаю, где он».zugo
03.08.2017 20:49+1Да, и при этом команды с сервисной шиной были, а CQRS — не было. На хрена они тогда?
AmdY
04.08.2017 00:18В этом и весь ад DDD, у каждого своё понимание, кто чего понахватался из большой синей книги, а то и вовсе из статей в интернете. Я пока не видел ни одного нормального проекта с DDD, который было бы легко поддерживать и расширять, потому отношу его к антипаттернам. И отсутствие интруменов для DDD ставлю в плюс Laravel.
franzose
05.08.2017 02:49Сам по себе DDD тут ни при чем. Штука в том, что PHP иногда — как российская глубинка: до него и его разработчиков некоторые вещи доходят с опозданием) В Java/.NET разговоры о DDD идут уже лет 15. Например есть хороший блог Александа Бындю на эту тему. Я думаю, это обусловлено, прежде всего, сферой применения.
AmdY
07.08.2017 03:31Да не проходило ничего мимо. Ещё во времена php4 все провали ddd и прочие технологии с java-asp, потому что литература по архитектуре была исключительно для этих языков. С тех пор появились более удобные инструменты как в самом языке, так и в сторонних библиотеках. Сейчас очередная волна, которая загнала язык в могилу, так как мы утратили преимущества — быстро, дешево, легкое в поддержке и маштабировании. Мы пришли на территории java-.net, с куда более ущербным языков в плане ООП.
Мы спорили о том, что DDD убьёт PHP ещё во время бет symfony 2, с тех пор практически все перешли к javascript или devops. При этом в большом мире начали уходить от энтерпрайзщины и спрингов, появился котлин.franzose
07.08.2017 08:44+1Сейчас очередная волна, которая загнала язык в могилу, так как мы утратили преимущества — быстро, дешево, легкое в поддержке и маштабировании.
Почему и когда мы их утратили?
Мы спорили о том, что DDD убьёт PHP ещё во время бет symfony 2, с тех пор практически все перешли к javascript или devops.
Практически все — это кто?
При этом в большом мире начали уходить от энтерпрайзщины и спрингов, появился котлин.
Ну и что, что появился. Все уже взяли и переписали всю свою кодовую базу на него?
franzose
05.08.2017 02:57Мне кажется вторая даже вреднее, так как люди тешат себя иллюзией о правильной архитектуре, а по сути вместо спагетти кода пишут лазанью.
Примеры лазаньи есть? Не сочтите за рекламу, но у меня есть пример того, как можно отделить бизнес-логику от хранилища: https://github.com/franzose/symfony-ddd-wishlist. Не знаю, насколько хорошо или плохо это вышло (вы можете оценить), но это можно сделать. И мапится на сущности/value object'ы всё прекрасно. На фронтенде только пока не вся логика, заложенная в «бизнес», реализована.
OnYourLips
03.08.2017 21:27+4по факту, для более-менее серьезного использования он годится только после доработки стандартного сетапа и нарушения всего, что говорит документация и предлагают авторы.
И обязательного выпиливания Eloquent (реализующего антипаттерн ActiveRecord) в обмен на Doctrine.
В итоге получается Symfony-подобная структура проекта и код на смеси Symfony и Laravel компонентов. И в следующий раз ты просто берешь Symfony, чтобы не переизобретать велосипед.
Однако в процессе написания первого такого проекта Laravel делает свое дело: обеспечивает низкий порог вхождения через себя в мир Symfony.zugo
03.08.2017 21:52+2Соглашусь. Причем следующим этапом будет отказ от framework-standard-edition и сборка своего решения из компонентов Symfony/Zend, чтобы не привязываться к системе бандлов.
Symfony Microkernel и грядущий Symfony 4 — шаги в очень правильном направлении.
SerafimArts
03.08.2017 22:42+2Я не хочу вдаваться в демагогию и что-то развёрнуто объяснять, но вы сильно ошибаетесь. По-этому — кратко:
Как симфони-разработчик и неоднократный докладчик на всяких симфонёвых митапах/конференциях, заверяю, что Laravel превосходит по всем параметрам Symfony, начиная с возможностей, заканчивая гибкостью и качеством конечного кода (естественно не ньюби, а адекватного разраба).
В качестве пруфов просто предлагаю сравнить возможности хотя бы одного компонента, давеча даже статья была https://habrahabr.ru/post/331982 Ну а после осознания того, как сильно Symfony DI отстаёт от Laravel — не писать подобные глупые высказывания, вроде "И в следующий раз ты просто берешь Symfony, чтобы не переизобретать велосипед". Думаю хоть тот факт, что процентов 80% того, что появилось в Symfony, с версии 2.8 — это из Laravel (начиная с того же автовайринга, .env и заканчивая flex и encore) убедит вас пересмотреть свою позицию.
franzose
04.08.2017 09:40+1Думаю хоть тот факт, что процентов 80% того, что появилось в Symfony, с версии 2.8 — это из Laravel (начиная с того же автовайринга, .env и заканчивая flex и encore)
Тем не менее, это появилось и этим можно пользоваться. В Symfony 3.3 конфигурация DI стала проще.
VolCh
04.08.2017 09:55+1А есть пруфы, что из Laravel именно, а не просто следование не то, что PHP-трендам, а вообще трендам современной разработки от Java до Erlang и Lisp?
c4boomb
04.08.2017 15:37Боюсь в данном случае именно Laravel задает тренды в PHP пусть даже заимствуя их из соседних языков.
VolCh
04.08.2017 15:53+1Быть первопроходцем не значит задавать тренды :) Это как с современными смартфонами — не Эппл придумала подобный формат, но Эппл задала тренд :)
c4boomb
04.08.2017 17:09То есть если условный Samsung выпустит ноутбук без разъема для наушников и все начнут этому следовать в мире ноутбуков, то не Samsung задал этот тренд?
BrainExploded
04.08.2017 17:16кстати, смарты без дырок для ушей — ещё одно подтверждение, что тренды и следование им — ужасная глупость. Надо делать как лучше, и следовать тому, что кажется более хорошим и удобным, а не тому, что модно.
franzose
05.08.2017 03:00Laravel — это в принципе такой аналог Ruby on Rails, тогда как Symfony — что-то вроде Spring, наверное. Doctrine вдохновляется Hibernate.
OnYourLips
05.08.2017 10:09+1Думаю хоть тот факт, что процентов 80% того, что появилось в Symfony, с версии 2.8 — это из Laravel
И что в этом плохого? Laravel делает хорошее дело — двигает отрасль вперед. Это авангард экосистемы PHP.
Консервативные серьезные фреймворки потом перенимают удачную часть этого опыта.SerafimArts
05.08.2017 16:58Я отвечал на коммент где написано было:
В итоге получается Symfony-подобная структура проекта и код на смеси Symfony и Laravel компонентов. И в следующий раз ты просто берешь Symfony, чтобы не переизобретать велосипед.
Моё замечание касалось того, что всё ровно наоборот =)
Casus
11.08.2017 14:51+1Не помню ни один из N*10 проектов чтоб мне не хватило возможностей DI в Symfony. Что про PSR-11 скажете?
backtrace из laravel — там же чёрт обе ноги сломит от вызовов callback и callable… День потратил чтоб разобраться почему laravel не смог в очередность инициализации зависимостей (при первом запуске, до создания кэша).
Про Eloquent выше всё сказали.
Laravel берёт не качеством а хайпом, но всё таки хорошо что он есть — конкуренция, это стимул к улучшениям.SerafimArts
11.08.2017 15:371) То что вам хватало — это замечательно. Целью было сравнение возможностей только одного компонента, а их, как известно, чуть более одного и у каждого возможностей и удобства больше. Даже у тривиального http-kernel, который, напоминаю, взят из Symfony.
Пара совершенно тривиальных примеров:// Обычное определение типа тела запроса: // Symfony $contentType = $request->headers->get('CONTENT_TYPE', 'text/html'); $isJson = $contentType === 'application/json' || substr($contentType, -5) === '+json'; //Laravel $isJson = $request->isJson(); // Его чтение: $result = @json_decode($request->getContent(), true); if ($result === false) { ... } // Laravel: $result = $request->json()->all();franzose
12.08.2017 01:49Пара совершенно тривиальных примеров
Это можно один раз завернуть в
ArgumentResolverи получится почти то же самое.
c4boomb
04.08.2017 15:13Отвечу про привязку к вендорским инструментам. Привязки нету, вы можете запускать лару как хотите, скачивать в зип архиве и тд и тп. Просто она позволяет в два клика использовать какой-то готовый пресет с помощью и без утилит. По итогу выбор за вами.
mykolaim
03.08.2017 15:53+3Laravel предлагает нам установить Homestead.
Можно еще сказать, что есть готовое окружение для Docker'a — http://laradock.io/
Очень понятная инструкция по настройке и установке, и как по мне это лучше чем качать целую VM для локального сервера.ElijahKaftanov
04.08.2017 20:22Хочу сказать, что поставить себе, как вы говорите ЦЕЛУЮ VM, очень просто (буквально 4 комманды на линухе). И это намного легче чем засорять себе компьютер кучей софта от php до redis'а. А готового сразу к использованию софта там действительно много. Так что если вы собераетесь химичить так, что ложатся огромные серверы, VM вам будет просто необходима)
SerafimArts
04.08.2017 20:27Кажется вы забыли прочитать комментарий. Попробуйте ещё раз первое предложение, в котором явно написано про то, что не надо ни ставить VM, ни ставить ничего локально, потому что докер — это ни то (на линуке, под виндой это всё же виртуалка), ни другое.
ElijahKaftanov
04.08.2017 20:53Ой, извините за мою дремучесть). Не знал о разнице между докером и вагрантом.
Тогда инфа для таких чайников как я: Докер — среда виртуализации, которая работает на одном ядре с ОС, тогда как Vagrant работает на отдельной виртуальной машине, что в свою очередь жрет дополнительную производительность.SerafimArts
04.08.2017 21:12А под линуком докер не под KVM пашет что ли? Я просто тоже чайник =)
ElijahKaftanov
04.08.2017 21:42Русская вики вещает о численном преимуществе докера над квм в производительности. Так что получается, что нет)
SerafimArts
04.08.2017 21:53Ох эта чёртова магия докера, хрен поймёшь что там =\
Но ходят слухи, что жизнь с одним ядром они победили с год назад. Теперь маются с ФС (в очередной раз переписывая всё заново).
VolCh
07.08.2017 05:02Докер — не система виртуализации в принципе. Грубо говоря, это продвинутый chroot, система предоставляющая исполняемым файлам изолированное окружение, но не изолированную машину.
mykolaim
04.08.2017 22:14увы, ваша информация немного устарела — под Windows 10 64-bit Professional, Enterprise и вроде Education — уже нативная поддержка, без VM.
SerafimArts
04.08.2017 22:15У меня Enterprise с последними патчами (наверное) и последний доступный докер (точно). Гоняется всё в Hyper-V (по крайней мере он стартует его при запуске), что я делаю не так?
gbezyuk
03.08.2017 17:23У меня один вопрос обычно ко всем пропагандистам Laravel: Django пробовали? =)
xelam
03.08.2017 17:41+1так рассуждая можно и другие языки\фреймворки вспомнить, а пока здесь речь о php only )
Northerner19
03.08.2017 19:13Django хорошо, но она на Python. Однако то что он популярнее не значит что на Laravel проекты создаются хуже. Да и к тому же комьюнити и поддержка у Laravel одна из лучших среди других MVC фреймворков )
AlexanderY
04.08.2017 11:59+1Использую Laravel несколько лет. Не фанат, не евангелист. Нравится, устраивает. Регулярно в подобных статьях вижу одного-двух людей, ругающихся на фасады и на невозможность писать в энтерпрайз-стиле.
1. Если я правильно понял, на фасады ругань из-за «магии». Вопрос: какое вам дело до «магии», если вы все равно точно знаете, какой будет результат при их использовании? Ну или объясните, в чем проблема, если я неправильно понял.
2. Объясните про энтерпрайз-стиль. Что это такое, конкретно? Что он дает (какие плюсы)? И почему на Ларе нельзя писать в этом стиле?VolCh
04.08.2017 12:54+1- Один из признаков энтерпрайз-стиля — разделение приложения на слабосвязанные слои. Дефолтная для Laravel ORM предлагает свою реализацию паттерна ActiveRecord, который по определению сильно связывает уровень бизнес-логики с уровнем хранения данных. Возможно, при должной дисциплине и(или) абстракциями поверх ORM можно отделить бизнес-логику от уровня хранения данных, вроде бы относительно легко прикрутить Doctrine для замены дефолтной, но в документации, постах и т. п. я не встречал такого подхода, а ровно наоборот подается как преимущество тесная свзяанность. Типа всего нужно написать $order = new Order(); $order.save(); и новая запись сохранена. В Doctrine это займёт минимум на строку больше.
AlexanderY
04.08.2017 13:09Спасибо за ответ. Я всегда считал «уровнем хранения данных» конкретную СУБД — mysql, postgres, mongodb и т.д. И в этом смысле любая ORM, включая Eloquent, добавляет нужный слой абстракции.
Я не понял, где связанность уровня бизнес-логики с уровнем данных в строчке "$order = new Order(); $order.save();". Именно в классе/модели Order? Если так, то что предлагает энтерпрайз стиль? Я вижу тут только удобство, не связанность. Модель не знает, как она хранится, в какой СУБД. Последняя, в свою очередь, ничего не знает о модели.VolCh
04.08.2017 13:41+1Да, имеено. ActiveRecord подразумевает две области отвественности у класса — сущность бизнес-логики и реализация персистентности (абстрагированной от конкретной СУБД через несколько уровней абстракции или прямо с SQL-кодом в классе — детали реалзиации). Сущность (модель) может и не знать в какой СУБД она хранится, но она знает, что она хранится, что может сохранить свое текущее состояние вызовом своего метода save().
DataMapper+Repository (обычно ещё некоторый набор паттернов для оптимизации удобства и целостности) же предлагают полную абстракцию от механизма хранения. Сущность — обычный класс, абсолютно ничего не знающий о том, что есть где-то СУБД или иное хранилище, у него нет методов типа save или delete. Репозиторий — класс, предоставляющий интерфейс коллекции, массива объектов этой сущности. Для всего остального приложения, кроме слоя хранения, есть по сути "вечный" массив простых объектов в ОЗУ, откуда оно может их брать, удалять и помещать им созданные.
michael_vostrikov
04.08.2017 14:01«Все остальное приложение» должно знать, что надо вызывать
$em->flush()чтобы сохранить изменения.zugo
04.08.2017 14:30+2Не-а, не должно. Это знает только инфраструктурный слой. Для остального приложения существуют лишь интерфейсы репозиториев.
michael_vostrikov
04.08.2017 15:24Ну так и
$order->save()вызывает только инфраструктурный слой. Я не защищаю ActiveRecord, если что, просто в обоих случаях надо знать, как сохранить объект.zugo
04.08.2017 15:32+1Если инстанс ActiveRecord используется не только в инфраструктурном слое, а и в доменном, то нет.
А если он используется только в инфраструктурном, то это уже не ActiveRecord, а Row Gateway. А если использовать его таким образом, то зачем тем более нужен Eloquent, можно обойтись и Doctrine\DBAL или Zend\Db.michael_vostrikov
04.08.2017 17:47Если где-то в доменном слое вызывается
save()у ActiveRecord, то там же будет вызываться методpersist()у entity manager. Там, где в инфраструктурном слое вызываетсяflush(), с ActiveRecord там же будет вызываться$transaction->commit().
VolCh
04.08.2017 15:40+1Ну так и $order->save() вызывает только инфраструктурный слой.
Это только при полном административном запрете дергать save() из других мест, прежде всего из самой сущности, что в целом нонсенс. На практике такого запрета либо вообще нет, либо он часто нарушается по принципу: "сейчас так сделаем, потому что дедлайн, а потом поправим", "потом" никогда не наступает.
просто в обоих случаях надо знать, как сохранить объект
В нашем случае нет такого понятия как "сохранить объект", есть "добавить объект в репозиторий". Всё. На уровне реализации репозитория add(SomeEntity $entity) как минимум дергается $em->persist($entity). И где-то по заверешнию бизнес-транзакции автоматически дергается $em->flush();
Да, в некоторых случаях надо где-то вручную дергать $em->flush(), но это где-то точно не на уровне бизнес-логики, а либо в уровне инфраструктуры, либо в уровне сервисов приложения. И всё равно это не "сохранить объект", а "сохранить все изменения".
michael_vostrikov
04.08.2017 17:38Но надо знать, что он есть, следить, чтобы он где-то вызывался после изменений. Потому что если незнакомый с фреймворком программист просто добавит объект в репозиторий и всё, то сущность не сохранится.
прежде всего из самой сущности
Ни разу не встречал, чтобы кто-то писал
$this->save()в модели. Административный запрет дергатьsave()это примерно то же самое, что административный запрет пробрасывать entity manager и дергатьflush(). Просто я к тому, что ActiveRecord создает не столько проблем, как принято считать, иначе бы давно все от него отказались, как от goto.VolCh
04.08.2017 17:42Потому что если незнакомый с фреймворком программист просто добавит объект в репозиторий и всё, то сущность не сохранится.
Именно, что сохранится. Нужно сильно постараться, чтобы не сохранилась.
Ни разу не встречал, чтобы кто-то писал $this->save() в модели.
Повезло. Мне встречалось и встречается постоянно.
Административный запрет дергать save() это примерно то же самое, что административный запрет пробрасывать entity manager и дергать flush().
Близко, но не одно и тоже. Проброс требует каких-то осозннанных действий, а $this->save можно получить просто по автодополнению в IDE.
michael_vostrikov
04.08.2017 17:54Именно, что сохранится.
Возможно я плохо знаю Symfony, но разве там есть встроенный автоматический вызов flush()? В примерах в документации flush() вызывается вручную в действиях контроллера.
Проброс требует каких-то осозннанных действий
Так вызов save() тоже. Я не представляю, зачем мне надо вызывать save(), если я не хочу в этом месте алгоритма сохранить модель. А если хочу, то и persist() вызову.
Кстати, а приведите пожалуйста пример, где вызывается $this->save(). Просто интересно, в каких случаях так делают.
zugo
04.08.2017 18:00+2Нет, он будет вызываться в реализации репозитория в слое инфраструктуры. Делать это в контроллере (да и вообще делать в контроллере что либо) — крайне плохая практика.
VolCh
04.08.2017 19:53В примерах в документации flush() вызывается вручную в действиях контроллера.
Общая беда многих документаций — примеры по основам фреймворка плохо подходят для реальных задач :( А так можно настроить, например, вызов flush при возникновении события типа нормального конца работы контроллера.
Я не представляю, зачем мне надо вызывать save(), если я не хочу в этом месте алгоритма сохранить модель.
Вы можете захотеть вызвать save внутри сущности, чтобы не забыть потом вызвать её снаружи сущности, особенно в случае сложных алгоритмов, где вам надо либо сохранять на месте, либо передавать наружу информацию, о том что эту сущность надо потом сохранить, что какой-то метод $order->cancel() изменяет сущность в отличии от метода $order->validate(). Причём не просто изменяет, а изменяет так, что это нужно сохранить.
Либо просто захотите уменшить повторяемость кода. Напишите в десятке мест что-то вроде $order->cancel(); $order->save(); и решите объединить действия по отмене зааза и сохранения результатов этих действий в один метод. Может просто добавите $this->save() внутрь cancel, может создадите метод $cancel->save(); Не может такое желание возникнуть?
А если хочу, то и persist() вызову.
Для вызова persist() внутри сущности вам нужно будет инжектить менеджер в сущность обычно с высокого уровня, а $this->save всегда под рукой — соблазна больше :)
michael_vostrikov
04.08.2017 22:01либо передавать наружу информацию, о том что эту сущность надо потом сохранить
В таких случаях обычно save() вызывается всегда. Если есть измененные поля, происходит UPDATE, если нет не происходит.
$order->cancel(); $order->save(); и решите объединить действия
Ага, понял о чем вы. Действительно, встречал такое пару раз. Но логичнее save() сущности вызывать там, где присходит валидация запроса на изменение — в контроллере или в методе save() класса формы с правилами валидации.
вам нужно будет инжектить менеджер в сущность
Не, я не о том. Если в алгоритме нужно сохранить модель, то в этот алгоритм надо обязательно пробросить менеджер. То есть нет никакой разницы, в одном случае у меня в алгоритме будет persist(), в другом save(), и в обоих случаях это осознанные необходимые действия.
michael_vostrikov
04.08.2017 22:02Кстати, делал как-то UnitOfWork для ActiveRecord. Все save() вызываются внутри него в методе commit(). Получилось довольно удобно.
VolCh
07.08.2017 05:13Если в алгоритме нужно сохранить модель, то в этот алгоритм надо обязательно пробросить менеджер
Тут вопрос куда и какими средствами его пробрасывать. Доктрина сопротивляется простым путям проброски менеджера внутрь сущности. Это возможно, но сложно в общем случае. В подавляющем большинстве случаев проще снаружи сущности вызвать методы менежера, чем инжектить их внутрь. Реализации же ActiveRecord делают всё, чтобы работа с менеджером была из сущности удобна, по крайней мере в кейсах типа $this->save()/$this->delete(), собственно это суть паттерна.
zugo
04.08.2017 13:45+2Не «невозможность» (благодаря неплохому DI-контейнеру эта возможность еще как есть), а неприятие этой практики в ларавел-сообществе.
1. Нет, не столько из-за «магии», сколько из-за сильной связанности. Если мы, например, инъектируем сервис по интерфейсу, то можем легко подменить реализацию, вообще ничего не меняя в зависящих от него классах и прочем. Причем интерфейс может находиться именно в нужном слое, ничего не знающем о реализации. Таким образом достигается слабая связанность.
2. Hexagonal, DDD, CQRS/Event-sourcing и тому подобные архитектурные паттерны. Он дает возможность писать большие, поддерживаемые, слабосвязанные проекты, с бизнес-логикой сложнее, чем круды. Писать на ларавеле в этом стиле можно, но мало кто так делает — ведь это же так здорово — дергать фасады где хочешь.
IvanShishkin
Спасибо. Очень интересно.
Ждем-с статей с техническими подробностями.