Меню

Ключові відмінності між 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 можна використовувати як для невеликих сайтів, так і для корпоративних, в тому числі через вбудовані системи кешування і високу продуктивность. Кожен з них потенційно є добре розширюваним, тому після того як ви вибрали фреймворк для нового проекту - подальша розширюваність залежить тільки від вас.

Реалізація структури бази продуктів з сервісу sql-ex.ru з підтримкою Doctrine2 16.09.2019 Реалізація структури бази продуктів з сервісу sql-ex.ru з підтримкою Doctrine2
Розширюйте проект на міцній основі з використанням вбудованого функціоналу Doctrine2, спробуйте додати свої класи і таблиці. Характеристика бази продуктів

Рекомендації по підключенню до API Amazon Marketplace Web Service (MWS) 13.09.2019 Рекомендації по підключенню до API Amazon Marketplace Web Service (MWS)
Як підключитися до Amazon MWS API? Процес отримання списку замовлень і формування підпису запиту з використанням декількох параметрів

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