Меню

Ключові відмінності між Laravel і Symfony

logo
Який з двох фреймворків Laravel чи Symfony вибрати для реалізації проекту? Під які конкретні потреби використовувати той чи інший фреймворк? Характеристика функціональних можливостей фреймворків
Ключові відмінності між Laravel і Symfony

Symfony або Laravel

В епоху існування великої кількості PHP-фреймворків перед PHP-розробником часто постає питання: за допомогою якого з фреймворків реалізувати проект?

Багато хто вже визначився з вибором, знайшовши найзручніший для себе фреймворк, а декому важко визначитися з відповіддю.

Розглянемо і порівняємо деякі з функціональних можливостей таких популярних фреймворків як Symfony і Laravel.

Установка

Основні файли сучасних PHP-фреймворків можна встановити за допомогою менеджера пакетів composer.

Так, для Laravel це можна зробити командою composer create-project --prefer-dist laravel/laravel project_name для Symfony composer create-project symfony/website-skeleton project_name, де project_name - ім'я проекту і в той же час - ім'я створюваної директорії, в якій composer розмістить файли фреймворку. У той же час обидві системи тепер мають свій інсталятор, laravel new project_name і symfony new project_name, а самі інсталятори можна встановити виконанням одного рядка: composer global require laravel/installer і wget https://get.symfony.com/cli/installer -O - | bash відповідно.

З цього видно, що процес установки мінімального функціоналу зведен до мінімуму втручання розробника і займає дуже мало часу.

Налаштування

Обидва фреймворка тепер підтримують .env-файл конфігурації, в якому зберігаються пари ключ-значення, але крім того Symfony також підтримує yaml-файли для настройки роутінга, сервісів та іншого.

Формат yaml дуже зручний у використанні і дозволяє вказувати значення параметрів конфігурації у вигляді, який за змістом нагадує багатовимірний масив.

Маршрутизація

Список маршрутів додатку і прив'язка до контролерів в кожному з фреймворків може бути задан по-своєму. Так, щоб вказати в Laravel, що маршрут "/test" повинен оброблятися методом test контролера TestController, в файлі роутінга routes/api.php потрібно вказати наступне: Route::get('/test', '[email protected]')->name('test_name');

Для Symfony те ж саме можна зробити за допомогою yaml-файлів, що відповідають за маршрутизацію, або, що дуже зручно, за допомогою анотацій

namespace App\Controller;

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class TestController {

    /**
     * @Route("/test", name="test_name")
     */
    public function test() {
         return new Response('Some test text');
    }
}

Використання контролерів має величезну кількість переваг. Так в шляху маршруту "/test" можна задати динамічні параметри, наприклад "/test/{id}". Тепер в сигнатурі контролера потрібно вказати параметр $id, а його значення буде підтягуватися з шляху. Також, динамічним параметрам можна задати формат за допомогою регулярних виразів, щоб наприклад $id було тільки цілим числом. Крім того, кожен фреймворк має функціональні можливості для об'єднання маршрутів в групи і присвоєння їм префіксів, присвоєння HTTP-методів, за якими будуть доступні ці маршрути, а також надає зручну підтримку роботи з GET- і POST-параметрами.

Міграції та ORM

Обидві системи пропонують зручний набір консольних команд для роботи з міграціями проекту, але мабуть ключова відмінність між Laravel і Symfony складається саме в роботі з ними. У Laravel ми самі змушені створювати міграції, а також нам самим доводиться стежити за синхронізацією структури БД і PHP-класів.

Так, наприклад, код міграції буде виглядати наступним чином:

Schema::create('tests', function (Blueprint $table) {
    $table->bigIncrements('id');
});

а клас Test буде виглядати наступним чином:

namespace App;

use Illuminate\Database\Eloquent\Model;

class Test extends Model
{
    protected $table = 'tests';
}

Бачимо, що всі моделі в Laravel успадковують клас Model.

У Symfony ж робота з міграціями здійснюється через Doctrine ORM. Тут ми можемо працювати тільки з PHP-класами і анотаціями. Так приклад коду для класу Test буде виглядати наступним чином:

namespace App\Entity;

namespace App\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity()
 */
class Test
{
    /**
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer")
     */
    private $id;
}

Після створення сутності Test ми можемо запустити створення міграції, де Symfony сама створить виконуваний SQL-код для створення таблиці tests з колонкою id. Більш того, нам не потрібно так ретельно стежити за синхронізацією структури БД і PHP-класів, тому що при створенні міграцій фреймворк порівнює поточну структуру БД і очікувану на основі поточних PHP-класів і створює весь потрібний SQL.

Варто зазначити, що для вибірок з БД в обох фреймворках передбачені ORM. У Laravel за це відповідає Eloquent. Так наприклад нижченаведений код дозволяє отримати колекцію об'єктів класу Test:

$tests = App\Test::where('id', '<', 100)
   ->orderBy('id', 'desc')
               ->take(10)
               ->get();

У Symfony подібний часто використовуваний код виносять в спеціальні класи - репозиторії, а тіло самого методу виглядало б наступним чином:

$tests = $this->createQueryBuilder('t')
            ->where('t.id < :id')
            ->setParameter('id', 100)
            ->orderBy('t.id', 'DESC')
            ->setMaxResults(10)
            ->getQuery()
            ->execute();

В цьому випадку повернеться масив об'єктів класу Test, а відповідати за це буде Doctrine ORM.

І Eloquent, і Doctrine реалізують шаблон проектування Fluent Interface, що можна бачити з назв методів where, orderBy та інших.

Шаблонізатори

З коробки Symfony працює з Twig, а Laravel - з Blade.

Їх функціонал дуже схожий, трохи відрізняється синтаксис. Шаблонізатори підтримують перевизначення блоків, успадкування файлів, цикли і багато іншого.

Найкраще відмінності буде видно з прикладів коду.

Twig:

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <title>{% block title %}Test Application{% endblock %}</title>
    </head>
    <body>
        <div id="sidebar">
            {% block sidebar %}
                <ul>
                    <li><a href="/">Home</a></li>
                    <li><a href="/blog">Blog</a></li>
                </ul>
            {% endblock %}
        </div>

        <div id="content">
            {% block content %}{% endblock %}
        </div>
    </body>
</html>

Blade:

<!DOCTYPE html>
<html>
    <head>
    <meta charset="UTF-8">
        <title>@yield('title')</title>
    </head>
    <body>
    <div id="sidebar">
        @section('sidebar')
            <ul>
                <li><a href="/">Home</a></li>
                <li><a href="/blog">Blog</a></li>
            </ul>
        @show
        </div>

        <div id="content">
            @yield('content')
        </div>
    </body>
</html>

Якщо вам знайом один з шаблонізаторів, то з іншим ви розберетеся без особливих проблем.
Що стосується front end-у, то Laravel також забезпечує підтримку Vue.js з коробки, що відкриває додаткові можливості, але в сучасному web не є неможливим використовувати будь-який PHP back end фреймворк в комбінації з JavaScript front end фреймворком, таким як React, Angular або Vue.js.
Як висновок можна сказати, що з двох великих фреймворків, Laravel і Symfony, не можна виділити найкращий, а тільки той, який більше підходить під конкретні потреби. Хоча в них реалізуються різні стратегії зі створення результуючого веб-додатка, жодну з реалізацій не можна назвати поганою. Обидва фреймворка дозволяють істотно розширити базовий функціонал для своїх потреб, а величезна кількість пакетів, що встановлюються за допомогою composer, тільки допомагають в цьому. І Laravel, і Symfony можна використовувати як для невеликих сайтів, так і для корпоративних, в тому числі через вбудовані системи кешування і високу продуктивность. Кожен з них потенційно є добре розширюваним, тому після того як ви вибрали фреймворк для нового проекту - подальша розширюваність залежить тільки від вас.

Реалізація підключення API Payoneer 10.09.2019 Реалізація підключення API Payoneer
Підключення до платіжної системи API Payoneer. Основні середовища підключення. Проходження користувачем реєстрації/авторизації за наданим посиланням, список користувачів

Поради щодо підключення до сервісу API ShipStation 17.09.2019 Поради щодо підключення до сервісу API ShipStation
Використовуйте API ShipStation як агрегатор для вашого сервісу, а такж як відмінний інструмент для економії коштів на відправленнях посилок. Опис особливостей сервісу

Повернення до списку