PHP-Дайджест № 150 (11 – 25 февраля 2019)


    Свежая подборка со ссылками на новости и материалы. В выпуске: изменены правила голосования за RFC в PHP Internals, стартовал прием заявок на доклады для PHP Russia 2019, новое расширение для реализации параллельного исполнения кода, свежие материалы для обучения, видео, порция полезных инструментов, и многое другое.

    Приятного чтения!



    Новости и релизы



    PHP Internals



    Инструменты



    Symfony



    Laravel



    Async PHP



    CMS



    Безопасность



    Материалы для обучения



    Занимательное



    Спасибо за внимание!

    Если вы заметили ошибку или неточность — сообщите, пожалуйста, в личку.
    Вопросы и предложения пишите на почту или в твиттер.

    Больше новостей и комментариев в Telegram-канале PHP Digest.

    Прислать ссылку
    Поиск ссылок по всем дайджестам
    Предыдущий выпуск: PHP-Дайджест № 149

    Поделиться публикацией

    Комментарии 10

      +3
      Как использовать паттерн «репозиторий» в Laravel

      Но там предлагают просто возвращать те же самые AR-модели… Уж если следовать паттерну, то нужно вводить слой сущностей (DTOшки, или аналог Entity в симфони), которые знать не знают о базе данных...

        +1
        Можно сделать интерфейс для модели и из репозитория возвращать интерфейсы.
          0
          В этом случае нужно думать о реляциях, типах и изоляции.
            0
            Я вот придерживаюсь идеи, что отдавать наружу связи — плохая идея. А вот метод, возвращающий коллекцию идентификаторов — вполне норм. Так что интерфейсы у моделей получаются достаточно чистыми.
            Главное, нужно рахделить чтение и запись. Запись через модели, а чтение отдельно, хоть рав запросами с нужными оптимизациями.
          +5
          Согласен, однако достаточно избыточно наращивать поверх AR слои с изоляцией, тогда мы теряем все его плюсы. Я в свою очередь очень много спотыкался об подобные вещи, сейчас AR уже давно не использую выбор пал в сторону DataMapper (Doctrine2).

          Если уже работать с AR то нужно принять правила игры.
            +4
            Раз в два-три месяца стабильно кто-то пишет про репозитории и Eloquent. и как «правильно» их использовать. Притом ни для чего они нужны, ни примера чуток посложнее Post у них не находится.
              –1
              Преимущества Active Record
              • Писать код с Active Record быстро и легко, в том случае, когда свойства объекта прямо соотносятся с колонками в базе данных.
              • Сохранение происходит в одном месте, что позволяет легко изучить, как это работает.

              Недостатки Active Record
              • Модели Active Record нарушаю принципы SOLID. В частности, принцип единой ответственности (SRP — «S» в принципах SOLID). Согласно принципу, доменный объект должен иметь только одну зону ответственности, то есть только свою бизнес-логику. Вызывая его для сохранения данных, вы добавляете ему дополнительную зону ответственности, увеличивая сложность объекта, что усложняет его поддержку и тестирование.
              • Реализации сохранения данных тесно связана с бизнес-логикой, а это означает, что если вы позже захотите использовать другую абстракцию для сохранения данных (например для хранения данных в XML-файле, а не в базе данных), то вам придется делать рефакторинг кода.


              Преимущества использовать Repository (паттерн Data Mapper)
              • Каждый объект имеет свою зону ответственности, тем самым следую принципам SOLID и сохраняя каждый объект простым и по существу.
              • Бизнес-логика и сохранение данных связаны слабо, и если вы хотите сохранять данные в XML-файл или какой-нибудь другой формат, вы можете просто написать новый Mapper, не притрагиваясь к доменному объекту.
              • Если вы пишете сложную бизнес-логику и хотите внедрить DDD, то использование паттерна Data Mapper лучшее, что можно придумать для отображения доменных моделей в таблицы бд (поля и таблицы могут не совпадать со всеми доменными моделями).


              Недостатки использовать Repository
              • Вам придется гораздо больше думать, перед тем как написать код.
              • В итоге у вас больше объектов в управлении, что немного усложняет код и его отладку.


              Как всегда, вопрос в расширяемости и гибкости кода, чтобы было проще поддерживать и дорабатывать. Стало понятнее?
                +1
                Ну, с википедии(или откуда там) и я смог бы скопипастить… вопрос был именно в использовании Элоквента и Репозитория вместе. Любая сущность с подсущностями и все рушится.
                  –1
                  и я смог бы скопипастить
                  Вы лучше попробуйте прочитать и понять.

                  Любая сущность с подсущностями и все рушится.
                  Почему это должно рушиться? В той же Symfony нормально живут описание зависимостей в модели, а получение данных через репозитории.

                  Напишите хотя бы один проект на Symfony и тогда в каждом проекте будет не хватать Doctrine с репозиториями.
                    +1
                    А самому прочитать внимательно? Доктрина с репозиториями — нормально. Элоквент с репозиториями — бесполезное жонглирование паттерном.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое