Меню

Ключевые отличия между 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;

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 Amazon Marketplace Web Service (MWS) 13.09.2019 Рекомендации по подключению к API Amazon Marketplace Web Service (MWS)
Как подключиться к Amazon MWS API? Процесс получения списка заказов и формирование подписи запроса с использованием нескольких параметров

Оптимизация веб-проекта — 3 способа ускорить загрузку веб-страниц 01.09.2019 Оптимизация веб-проекта — 3 способа ускорить загрузку веб-страниц
Вы разработали дизайн сайта, подобрали соответствующие теме картинки и заказали дорогой текст для лендинга, но количество посещений минимальное. Если Вам знакома такая ситуация, не спешите вкладываться в контекстную рекламу и другие сервисы для увеличения числа посетителей. Прежде всего, Вам нужна оптимизация сайта.

Возврат к списку