- Laravel
- Компоненти фреймворків: порівнюємо Laravel і Symfony
- HTTP fundamentals & MVC pattern (Controllers, Routing, Views)
- ORM Eloquent vs. Doctrine ORM
- Artisan vs. Console Commands
- Service Container
- Templating: Blade vs. Twig
- Debug and error handling
- висновки
- Коментарі
Всім привіт, мене звати Андрій і я симфоністом. Нещодавно ми почали невеликий проект по додатковій розробці до існуючої SAP системі. Перед початком розробки мені запропонували самостійно вибрати набір необхідних інструментів, і я вирішив подивитися щось крім рідної і знайомої Symfony .
Особливість проекту полягала в тому, що в основному нам треба було працювати через SoapClient з веб-сервісами. C їх допомогою будувався інтерфейс для взаємодії користувача і невеликої частини ERP системи . Ніяких складних структур під бізнес-вимоги будувати не потрібно. Робота з БД обмежувалася зберіганням даних для авторизації користувачів і підтриманням декількох таблиць з настройками. У той же час система спочатку не мала на увазі подальшого розвитку в щось велике і складне. По суті, потрібно реалізувати тонкий клієнт для роботи з сервером веб-сервісів.
Не можна сказати, що Symfony не підходив для вирішення завдань проекту, але мене бентежило кількість коду, яке треба було написати, щоб він був "Symfony way". Тому я вирішив подивитися в бік більш простих інструментів.
Мій вибір припав на Laravel. Якщо судити з відгуків в інтернеті, він досить простий в освоєнні, має велике ком'юніті і добре показує себе в реалізації невеликих і простих проектів. Чого гріха таїти, мене спокусило використання компонентів Symfony в фреймворку, і я давно хотів подивитися наскільки ефективно вони використовуються в рамках інших проектів.
Laravel повністю виправдав мої очікування:
- Досить легко і швидко встановлюється
- Простий і зручний в розробці
- Можна відразу ж почати писати промисловий код
На підставі мого першого враження я підготував невеликий огляд фреймворка, його архітектури та компонентів.
Laravel
Фреймворк - це якийсь кістяк структури проекту, що надає реалізований функціонал "з коробки". Даний функціонал дозволяє вирішувати найбільш типові завдання при розробці. Архітектура фреймворка може як реалізовувати якийсь власний набір патернів, так і являти собою реалізацію окремих загальновідомих патернів.
Архітектура Laravel будується навколо популярного останнім часом принципу Inversion of Control >> Dependency Injection >> Service Container. Цей принцип добре знайомий розробникам Symfony, тому що є наріжним каменем всієї Symfony розробки.
Service Container Laravel дуже нагадує Symfony з незначними відмінностями. Це не дивно, адже він реалізує той же патерн, хоч і трохи інакше. В цілому ж треба зазначити, що саме Service Container обділений увагою в документації Laravel. Ймовірно, розробники фреймворка не вважають такий компонент центральним в його побудові. Хоча, можливо, докладний опис опущено, щоб не ускладнювати документацію і надати розробнику можливість орієнтуватися в роботі з компонентом по ситуації.
Більш докладно про принцип Inversion of Control і патернах його реалізують (DependencyInjection >> Service Container; і (анти) паттерне ServiceLocator) можна подивитися тут:
Laravel використовує частину компонентів Symfony. Це не означає, що компоненти впроваджуються "копіпастом" і, відповідно, працюють за принципом «досить тільки прочитати документацію оригіналу і можна використовувати». Швидше компоненти вдало вплетені в структуру фреймворка, десь трохи змінені (обгорнуті), десь доповнені і підлаштовані для відповідності "екосистемі" фреймворка. Насправді, це досить логічно, тому що багато компонентів Sf поставляються як готовий до використання код і добре вирішують завдання, які ставляться перед фреймворками на загальному рівні.
Компоненти фреймворків: порівнюємо Laravel і Symfony
Так як я симфоніст і дивлюся на все очима симфониста, то спробую порівняти рішення фреймворків Laravel і Symfony.
HTTP fundamentals & MVC pattern (Controllers, Routing, Views)
Отже, давайте повернемося до коріння веб-розробки, зокрема до протоколу HTTP. Що б не робив ваш серверний код, в кінцевому підсумку він повинен отримати якийсь запит, обробити його і повернути певну відповідь. Якщо використовувати plain PHP, можна досить легко заплутатися, наприклад, з тілом відповіді і поверненням заголовків відповіді. Якщо ви вже давно в розробці, то варто згадати "Headers already sent" і ви відразу все зрозумієте.
Щоб уникнути атак, можна семуліровать роботу із запитом і відповіддю як роботу з парою відповідних класів (об'єктів). Компонент HTTPFoundation Symfony служить саме цієї мети. Він же використовується в Laravel і дозволяє змоделювати роботу на рівні HTTP протоколу. Простий і зручний у використанні. За прикладами використання welcome в документацію.
Патерн MVС всім добре відомий, тому досить сказати, що в Laravel він реалізований. Реалізовано вельми стандартно: є звичні контролери з actions, окремий рівень з поданням, з використанням шаблонізатора і все, що розуміється під моделлю.
Простий екшен в контролері може виглядати приблизно так:
public function postResetPassword (Request $ request) {$ user = Auth :: user (); if (! $ user) {return redirect () -> action ( 'AuthController @ getLogin'); } $ User-> changed_by_user = true; $ User-> password = $ request-> input ( 'password'); $ User-> save (); return redirect () -> action ( 'UserController @ getInfo', array ()); }
Тут ми перевіряємо, авторизований користувач, і міняємо його пароль. Варто звернути увагу, що екшен приймає в якості аргументу об'єкт класу Request, який в свою чергу успадкований від класу Request, що йде в складі HTTPFoundation Symfony:
use Symfony \ Component \ HttpFoundation \ Request as SymfonyRequest; class Request extends SymfonyRequest implements Arrayable, ArrayAccess
ORM Eloquent vs. Doctrine ORM
Досить стандартної завданням при веб-розробці є збереження об'єктів в базу даних і читання з бази даних. Для роботи з БД використовуються так звані Моделі. У Laravel процес роботи з БД здійснюється за допомогою ORM Eloquent.
Eloquent використовує патерн Active Record, який значно простіше патернів DataMapper, Unit of Work і Identity Map. Останні використовуються в ORM Doctrine, яка є базовою ORM для Symfony. Робота з Eloquent за рахунок простоти має безліч переваг. Мабуть, найголовніші: небагатослівність при описі моделей і простота використання в коді. При створенні моделі зовсім не обов'язково описувати кожен аксессор, досить звернутися до властивості за назвою поля в БД.
Приклад роботи з Eloquent (з офіційної документації):
$ User = new User; $ User-> name = 'John'; $ User-> save (); $ User = User :: find (1); $ User-> email = '[email protected]'; $ User-> save ();
Простота має і зворотну сторону - за замовчуванням, підказок в IDE не варто чекати через відсутність описаних методів / властивостей. Цю проблему допомагає вирішити laravel-ide-helper, який генерує коментарі до моделей.
Також є кілька зручних опцій на зразок вбудованого генератора міграцій або простого опису зв'язків між моделями. В цілому, Eloquent зручний для розробки моделі невеликого і середнього розміру. Наскільки він підходить для роботи з великою моделлю сказати складно, але можу припустити, що його потужності може виявитися недостатньо.
Artisan vs. Console Commands
Як і практично в будь-якому сучасному фреймворку, в Laravel є потужний інструмент для роботи з консоллю. У Laravel цей компонент називається Artisan (ремісник, майстер). Він надає широкі можливості по виконанню різних рутинних операцій. В основному там зосереджені генератори коду (міграції, моделі, контролери, слухачі та інші). За допомогою artisan можна управляти чергами завдань, виконувати операції за розкладом, очищати кеши, і багато що ще. Крім цього, дуже легко писати свої команди. Для цього треба створити клас команди і зареєструвати його. Також можна створювати ланцюжки з команд, викликаючи їх один з одного.
Наприклад, якщо ми хочемо створити нову модель, то нам досить запустити в консолі наступну команду:
$ Php artisan make: model User
Artisan небагато чим відрізняється від стандартних консольних компонентів інших фреймворків. Важливо знати, що він є і він працює. Моя улюблена команда php artisan inspire :).
Service Container
Як я вже згадував раніше, архітектура Laravel побудована на базі паттерна Service Container. В цілому, його реалізація дуже схожа на реалізацію в Symfony, хоча є невеликі відмінності.
Коли працюєш з Symfony, намагаєшся дотримуватися даного патерну і протягувати залежності нехай і через складні шари абстракції. Весь фреймворк побудований на ідіоми сервісів, і отримати об'єкт певного класу не завжди можливо безпосередньо, потрібно звертатися до відповідних сервісів по його отриманню.
Laravel в цьому плані не настільки заморочені. У розробника в цілому розв'язані руки, і я встиг зустріти кілька прикладів того, що необхідні методи або об'єкти виходять викликами через статичні інтерфейси. У загальному випадку це є порушенням принципу шаблону, але нічого кримінального в цьому немає, це вже як кому подобається і підходу до розробки.
Templating: Blade vs. Twig
Подання реалізовано на базі шаблонізатора Blade. Це звичайний шаблонизатор. Присутні вбудовані оператори (на кшталт if), можливо перевизначення частин шаблонів, є зручні генератори для отримання html блоків, можна провести доступ до потрібних сервісів, можна навіть написати власну директиву.
Blade здався здався мені менш зручним, ніж Twig. Хоча фреймворк Laravel в цілому значно простіше Symfony, саме шаблонизатор для Symfony, на мій погляд, виглядає простіше для освоєння.
Debug and error handling
У Laravel присутній режим розробки, в якому розробнику стає доступна спеціальна панель на кожній сторінці. У дебаг панелі можна подивитися, що відбувалося на стороні фреймворка для формування відповіді сервера. Наприклад, там можна побачити список виконувалися запитів до БД, що спрацювали виключення, відправлені е-мейли і інше. Панель дуже сильно схожа на дебаг панель Symfony, але при цьому вона значно програє в потужності.
Можна сказати, що творці фреймворка Laravel досить подбали про розробників: крім дебаг панелі, система може Залогуватися все, що в ній відбувається, присутні автогеренатори коду. Також передбачена спеціальна функція dd для виведення ряду даних в процесі розробки на екран.
висновки
В цілому, загальне враження про промислову роботі з фреймворком Laravel залишилося хорошим. Що стосується швидкості розробки, то вона може бути значно вище, ніж при роботі з Symfony. Простота фреймворка і його відносна небагатослівність значно скорочують час, який доводиться витрачати безпосередньо на написання коду. У фреймворку є багато булочок, які полегшують життя розробника, це теж дає хороший буст.
Для установки фреймворка і роботи зі сторонніми бібліотеками використовується composer, так що установка і оновлення зовнішніх бібліотек не представляє особливих труднощів. Окремо варто звернути увагу на продуктивність Laravel. Фреймворк нескладний і, відповідно, здебільшого швидкий. Якихось спеціальних бенчмарков я не використовував, але по відчуттях і швидким поглядам на дебаг панель (ах да, там ще можна побачити загальний час виконання скрипта) виграш в швидкості очевидний.
Трохи розчарувала документація. Хоча вона і представлена, але в дуже обмеженому вигляді. Думаю, коли її складали, розробники керувалися тим же принципом мінімалізму, що і при побудові фреймворка. Вона охоплює тільки основний функціонал, а решта чудеса фреймворка потрібно досліджувати самому, або шукати в Інтернеті. Добре, що Laravel вельми поширений, і у нього велике ком'юніті - практично будь-яку проблему, з якою ви зіткнетеся, давно вирішив хтось інший.
Наостанок хочу додати, що фреймворк (треба віддати честь його розробникам) на практиці виявляється рівно таким, яким його позиціонують. Це простий і зручний інструмент для "майстрів" в тих випадках, коли їм не потрібно заглиблюватися в усі тяжкі Ентерпрайза.
Коментарі
коментарі
