Я очень люблю экспериментировать. И вот после очередного разговора про ограничения xPDO я подумал, а почему бы не попробовать тот же Eloquent из Laravel. Его возможности сильно опережают xPDO и в плане функциональности, и в плане безопасности, и в плане оперативности поддержки. Для человека владеющего Composer'ом нет ничего невозможного. Всего одна команда

composer require illuminate/database

и готово дело. После подключения к базе, которое заняло пару минут, сразу же доступен Query Builder. Запросы к БД можно писать в «текучем» стиле:

// Все пользователи
$users = DB::table('users')->where('active', 1)->orderBy('username', 'asc')->get();
// Отдельные данные пользователя
$email = DB::table('users')->where('username', 'admin')->value('email');
// Работа на уровне базы
DB::statement('truncate table prefix_session');

В документации много примеров. Я не все ещё возможности опробовал. Та же пагинация сходу не запустилась (нужно доустанавливать отдельный пакет). Но что удобно — результат возвращается не массивом, а коллекцией. Это специальный класс с огромным количеством методов для манипуляции данными.

Для работы с данными через Eloquent (напомню, что это ORM) пришлось ещё немного потрудиться. А именно — создать несколько классов:

// Класс ресурсов
class Resource extends Illuminate\Database\Eloquent\Model {
    public $table = 'site_content';
}
// Класс пользователей
class User extends Illuminate\Database\Eloquent\Model {
    // Связь с таблицей профилей
    public function profile(){
        return $this->hasOne('Profile', 'internalKey');
    }
}
// Класс профилей
class Profile extends Illuminate\Database\Eloquent\Model {
    public $table = 'user_attributes';
    // Связь с таблицей пользователей
    public function user(){
        return $this->belongsTo('User', 'internalKey');
    }
}

И всё!!! Никаких схем, головной боли с добавленными полями и т.п. Даже свойство с названием таблицы можно было бы не указывать, если бы они назывались согласно правилу Laravel:

Имя таблицы — это название класса во множественном числе.

Этому правилу соответствует только таблица users. Сравните с xPDO.

Теперь я могу получить ресурсы и пользователей так

// Первый из списка ресурсов, в заголовках которых есть слово "modHelpers".
$resources = Resource::where('pagetitle','LIKE','%modHelpers%')->first();
// Пользователь с id 1.
$user = User::find(1);
// Данные профиля
$profile = $user->profile;

Ещё обратите внимание на Query Scopes. Удобная вещь. Можно создать скоуп (метод класса) для получения тикетов, чтобы можно было писать такой запрос:

$tickets = Resource::tickets()->get();

Или просто создать отдельный класс, который будет работать только с ресурсами класса Ticket:

// Получить все тикеты, у которых есть хоть один комментарий
$tickets = myTicket::has('comments')->get();

Таким образом можно легко расширять любые классы и не думать обо всех этих схемах и т.п.

Из коробки доступен функционал поиска по JSON полям:

$users = DB::table('users')
                ->where('options->language', 'ru')
                ->get();

Можно писать так называемые сырые запросы:

$users = DB::table('users')
                ->select(DB::raw('count(*) as user_count, active'))
                ->where('active', 1)
                ->groupBy('active')
                ->get();

Ещё плюсом идёт логирование всех обращений к базе данных. Благодаря чему возможно увидеть все запросы к БД. Эту фичу использует мега пакет Laravel-debugBar. В MODX об этом можно только мечтать.

Кроме того прямо из коробки вы получаете работу со связями «Многие-ко-Многим». Разработчики обязательно это оценят.

Что ещё? Памяти занимает около 3 Мб. Немного. В общем, обо всех возможностях в одной статье не расскажешь. Да и не было такой задачи. Кому интересно, есть документация Ларавел. Там много примеров. Лично я принял решение поставить Eloquent себе на сайты. Ибо работать с ним мне гораздо комфортнее как программисту. Можно было бы и пакет собрать. Но боюсь его ждёт судьба Middlewares. Так что тратить время даже не буду. Как и на разные видео.

07 февраля 2018, 18:34   797     9

Комментарии ()

  1. Vitaliy 07 февраля 2018, 20:36 # +1
    Middlewares хорош, кому надо пользует, спасибо)
    А по теме возникает вопрос, зачем тогда MODX?
    1. Сергей Шлоков 07 февраля 2018, 23:24 # +2
      Бинго! Вопрос в точку :)
      Но ответ достаточно простой — привычка и уверенность в результате. Многие хорошие разработчики владеют только MODX. Вот наглядный пример такого подхода. И админка не используется, и структура фреймворковская и инструменты, и элементы файловые. А всё равно отказаться от MODX никак.
      Я кстати тоже не испытываю терзаний по этому поводу. Я хорошо знаю MODX и не хочу от него отказываться.

      На самом деле Eloquent расширяет возможности MODX. Он как дополнительная турбина для двигателя. А в MODX есть полноценная админка и готовый базис — настройки, кэш, лексиконы, права, менеджер дополнений, логирование и многое другое. xPDO из MODX конечно не выпилишь. Но и с ним использовать Eloquent при разработке очень даже просто. Его, кстати, включить в какое-то свое дополнение даже проще, чем Middlewares.

      Лично я уже принял для себя решение. Тот же Тикетс легко переводится на Eloquent — нужно лишь создать несколько простых классов. Также тэги легко ложаться. И ещё несколько моментов прямо ждут Eloquent. Так что у меня есть над чем в ближайшее время работать.
      1. Vitaliy 08 февраля 2018, 11:30 # +2
        Буду ждать продолжения. Всегда интересные эксперименты и рецепты.
    2. Konstantin 15 февраля 2018, 21:57 # 0
      Нормалек, но все равно не хватает кучи других штук из Laravel Way) Штуки нашел в October CMS система хороша.
      1. Konstantin 15 февраля 2018, 22:18 # 0
        1) Скорость разработки своих плагинов ограничивается только скилом.
        2) Много готовых штук и других мега возможностей, под капотом в большинстве понятный и приятный код.
        3) В админке можно «гавнокодить» на jquery добавлять так свои формвиджеты на основе плагинов jquery + считай многие виджеты уже написаны.
        4) Для моделей CRUD на yaml конфигах, и не тупой вывод инпутов а множество разных вариаций формвиджетов.
        5) Очень расширяемые классы системы.
        6) Весь сахар Laravel и возможность использовать идеи для своего кода.

        Вообщем если бы меня спросили есть ли cms на которой реал нет ограничений и тебе не надо писать много чтобы получить мало, то ответил бы October CMS.
        И еще высокая скорость освоения системы.
      2. shock 17 февраля 2018, 13:53 # +1
        Спасибо интересно было почитать.
        Думается, что кто-то время опережает или подкидывает идеи развития. В любом случае благое дело! По-возможности не останавливайтесь.
        1. Сергей Шлоков 17 февраля 2018, 22:02 # 0
          Спасибо!
          Но боюсь, если не останавливаться, то дорога приведёт к Ларавел. Я никого не призываю следовать моим путём. Просто делюсь своим опытом. Ибо два года никак не мог решиться начать освоение Лары. И вот для таких же испытывающих страх перед новым, делаю такой «мостик». Попробовав разные приемы из Ларавел дальше будет уже не страшно.
        2. Егор 04 апреля 2018, 20:49 # 0
          Сергей, спасибо за статью, очень интересно!
          А по производительности можете что-то сказать (не абсолютная, а относительно xpdo)?
          Заранее спасибо =)

          Построитель запросов, судя по тестам, сильно обходит Eloquent по скорости. Надо дальше разбираться =)
          1. Сергей Шлоков 05 апреля 2018, 06:10 # 0
            Я не сравнивал. И Eloquent и xPDO используют PDO. Поэтому большой разницы не будет.

          Вы должны авторизоваться, чтобы оставлять комментарии.

          Выделите опечатку и нажмите Ctrl + Enter, чтобы отправить сообщение об ошибке.