В прошлой статье мы разобрались как в Laravel работать с UUID. Но он не решает всех проблем распределенных систем. Один из новых подходов к генерации уникальных идентификаторов это ULID — Universally Unique Lexicographically Sortable Identifier (универсальный уникальный лексографически сортируемый идентификатор).
Сравнение UUID и ULID
Во многих случаях использование UUID неоптимально:
- Это не самый эффективный способ кодирования 128-битной случайности
- UUID v1/v2 непрактичен во многих средах, так как требует доступа к уникальному стабильному MAC-адресу
- UUID v3/v5 требует уникального начального числа и генерирует случайно распределенные идентификаторы, которые могут вызвать фрагментацию во многих структурах данных
- UUID v4 не предоставляет никакой другой информации…
ИМХО, совершенно недопустимо изменять данные в Представлении. У кого-то может возникнуть такой соблазн, типа, для "оптимизации". Счётчик какой-нибудь посчитать и сохранить. Но не надо так делать! Потому что это портит логику и усложняет сопровождение.
Что же до "обращения к базе" в смысле операций чтения, в идеале да, они должны все происходить до обращения к Представлению. Но мы же сами добиваемся абстракции, когда чтение свойства объекта может неявно сопровождаться каким-то действием. Представление понятия не имеет делали мы eager loading или нет. Оно просто использует объект. Короче, врядли удастся избежать select в 100% случаев. По причине именно "объектности", "принципа чёрного ящика". Мы не всегда знаем как что-то работает внутри. Мы знаем только внешний эффект.
Недавно автор статьи Povilas опубликовал свой приём по внедрению данных в шаблон: через инъекцию сервиса (@inject), который рендерит свою вьюху и возвращает её как текст для вставки. Внутри такого сервиса очевидно будут операции с базой и как по мне это не очень страшно, если они не изменяют состояние.
Calculations in Blade, without violating MVC? Use Service Injection