Всем привет. Хочу вам признаться и немного рассказать о том, что я чувствую, когда разрабатываю в Laravel. Нет, не подумайте, я обожаю этот фреймворк и невероятно благодарен команде, которая его создала и поддерживает, они делают крайне крутую работу и, на мой взгляд, Laravel — лучшее продолжение моей не менее любимой Symfony. Я люблю тупой код. Тупой в том смысле, что даже через 10 лет, если заказчик попросит внести в него изменения, вы сможете это сделать, не вникая во всю логику, даже после пятничного корпоратива, ничего не нарушив в старом коде.
И глупо в том смысле, что вам не нужно прилагать никаких когнитивных усилий, чтобы понять это.
Но в Laravel Eloquent ORM есть одно архитектурное решение, которое заставляет меня плакать.
Интересный? Иди к коту.
Умные люди уже давно все для нас придумали: ООП, Паттерны проектирования, SOLID, DDD и другие страшные слова, которые поначалу так пугают, а потом используются по наитию.
Мне нравится Laravel и Symfony. Они позволяют писать самый глупый и безопасный код прямо из коробки.
Да.
У каждого из них есть свои недостатки.
Но у Laravel есть один, который меня раздражает больше всего.
Это использование Active Record Pattern (AR) для работы с моделями.
Сначала немного об этом шаблоне.
Что это вообще такое? Чтобы разобраться, следует обратиться к родителю этого опуса дизайна приложения — паттерну «Репозиторий».
Этот шаблон представляет собой коллекцию.
Коллекция сущностей (Entity), которые можно извлекать, изменять, сохранять, удалять и которыми обычно можно управлять в абстрактном месте хранения.
В 90 из 100 процентов случаев этим местом хранения являются различные базы данных.
Но там может быть файловая система, какой-то кэш и даже внешний API. Этот подход полностью соответствует принципу единой ответственности и подходу DDD. Кроме того, благодаря такому подходу реализуется слабая связанность — нам не важно, как именно что-то хранится в приложении, мы работаем с Entity, когда хотим работать напрямую с объектным представлением данных, и работаем с Repository, когда нам нужно.
для взаимодействия с хранилищем.
Но Laravel решил пойти по пути использования AR, что, несомненно, круто и невероятно удобно, когда нужно сделать быстрый прототип, но становится невероятной головной болью, когда нужно взаимодействовать с несколькими источниками данных и оперировать ими внутри системы.
AR — это шаблон, который отображает сущность и репозиторий в одну модель.
То есть объект становится представлением конкретной записи в базе данных.
И что? К чему это приводит и почему это так раздражает? Во-первых, мы нарушаем тот же принцип единой ответственности — логика работы с репозиторием в одном месте, а логика работы с сущностью в другом.
Это важно, поскольку в моей системе я не хочу передавать строку из базы данных в представлении объекта через цепочку вызовов.
Я хочу передать модель.
Меня не должно волновать, как это создается, изменяется и сохраняется.
Мне нужно иметь те методы, которые позволяют взаимодействовать только с моделью, а не со строками в базе данных.
Во-вторых, мы не можем (вследствие того, что Persistent Layer — уровень хранения — подключен к сущностному слою) просто изменить место хранения модели.
Да, мы можем сделать это в конфигурации, изменив это для всех сразу, в рамках поддерживаемых баз данных.
Либо менять только под конкретную модель (при этом мы не удаляем никакие методы построения запросов, потому что от методов базового класса не избавишься) и нарваться на массу вероятных ошибок в коде или, не дай бог, если кто-то другой поддержит ли он (и это происходит постоянно).
Третий.
Я хочу протестировать свои сущности.
Я хочу быть чертовски уверен, что вносимые мной изменения не нарушат мою бизнес-логику.
Но, как показывает практика, в случае с АР этого сделать нельзя, потому что нарушается проклятый принцип единой ответственности! Хотя здесь я немного лукавлю.
Тестировать модели можно, просто… Это немного непросто.
Однако нельзя не упомянуть и о преимуществах данного шаблона.
Хотя все его преимущество в том, что это «быстро, просто, не задумываясь».
Объединив два паттерна, близких по логике своего действия и постоянно используемых вместе, мы получили удобный инструмент, немного уменьшающий объём кода (в сторону сложности, мы помним про «тупой код»?).
Это также позволяет избавиться от ненужных проблем на этапе формирования MVP, который обязательно (практика показывает, что такое случается редко, но все же) планируется переписать.
Это позволяет сместить мысли с вопроса «как мы делаем» на вопрос «что мы делаем», то есть избавиться от ненужных вопросов о технологиях и перейти к бизнес-логике.
К какому выводу я пришел после нескольких лет использования Laravel Eloquent ORM? Active Record – это зло во плоти? Нет, это крутой инструмент для некоторых ситуаций, особенно для этапа, когда пишется простое приложение или прототип такого приложения.
Но с этим невозможно работать, когда ваше приложение растёт и вам приходится работать с большим количеством источников данных, писать код со 100% тестовым покрытием, начинаются большие проблемы.
Да, придумываются новые фокусы( Дальнобойщик ?), пойдем на хитрости.
Но мне все же хочется немного больше свободы от фреймворка, тем более, что это хорошо для стольких людей! Теги: #Laravel #шаблоны проектирования #activerecord #Eloquent ORM
-
Зачем Калибровать Аккумуляторы Ноутбуков?
19 Oct, 24 -
Livescribe Pulse Smartpen
19 Oct, 24 -
Почему Не Стоит Учиться На Программиста
19 Oct, 24
