Задать вопрос
Ответы пользователя по тегу Паттерны проектирования
  • Как грамотно реализовать одно соединение с базой данных на все приложение, с помощью Dependency Injection Container?

    @Vitsliputsli
    Создать зависимость можно только 2 способами, получив объект изнутри или проведя инъекцию снаружи. Если изнутри, то так или иначе понадобится синглтон, если снаружи, то ктото снаружи должен контролировать передачу одного и того же объекта во все нуждающиеся объекты.

    1. Изнутри. Очевидно просто инстанцировать объект - это очень плохой вариант. Более менее нормальный вариант, это сервис локатор, с методом возвращающим нужный объект работающим как синглтон (т.е. не нужен прям класс синглтона, только метод который проверяет существует ли объект). Выглядит это не очень, синглтон и сервис локатор не считают хорошим решением. Из минусов статичное обращение к сервис локатору создаст проблемы для подмены объекта. Для разных подключений вы можете создать отдельные методы сервис локатора или разрулить в одном методе динамический выбор. Реальная проблема - тестирование, вы не сможете мокировать объект работы с БД. Но, можно это сделать ухищрениями, сделав ленивое подключение, и метод подмены объекта БД, хотя придется этот метод тащить в каждый класс. Как вариант, делать инъекцию объекта сервис локатора. Но остается другой большой минус, сервис локатор "гвоздями прибит" к большинству классов и вам придется его везде таскать, т.е. о красивых компонентах без странной зависимости от сервис локатора можно забыть.
    2. Снаружи. Оптимально, и считается трендом - инъекция нужного объекта в конструктор. Будет ли это делать DIC или чтото иное не имеет значения. Не нужно таскать какието дополнительные сервис локаторы. Но данное решение имеет тот же минус, что и п.1, вы не сможете подменить объект на другой при мокировании:
    public function __construct(PDO $db)
    внедряемый объект обязан быть классом PDO, если хочется чтобы мок просто подсовывал одни и те же значения нужно менять на интерфейс, тогда моку достаточно выполнять требования интерфейса. Но, если ваш DIC использует автоматическое определение требуемых объектов по структуре конструктора, то использовать интерфейс не получится.
    Ответ написан
    Комментировать
  • Вопросы по архитектуре проекта: service layer и action domain responder?

    @Vitsliputsli
    Но если поместить это в сервис, то открыв класс сервиса, мы увидим вообще все кейсы работы с сущностью "пост", а если писать это в контроллере, то логика уже чуть размазывается по приложению.

    Сервисный слой или модели в MVC - это не класс, не объект. Это код отвечающий за доменную логику, там никто Single Responsibility не отменял, делите сущности по их ответственности, и создавайте столько классов, сколько необходимо.

    И вопрос, а чем же всё таки являются actions? Это больше контроллеры одного действия, или больше сервисы одного действия? Поскольку в сети мнения на этот счёт расходятся.

    Очевидно, что actions - это обычные контроллеры. Вообще, ADR - это тот же MVC, с абсолютно таким же делением на controller-action, model-domain, view-responder. Автор ADR утверждает, что там связи более правильные. Но в отличиях ADR от MVC, автор приписывает MVC какие-то ужасы, типа вьюха при желании лезет в модели что-то там запрашивает и т.п., чего в MVC нет и никогда не было. Такое ощущение, что автор ADR просто открыл для себя как правильно пользоваться MVC.
    Ответ написан
    Комментировать
  • Что такое модель в ООП в веб?

    @Vitsliputsli
    Контроллер, представление, модель - это элементы MVC, к ООП отношения не имеют.
    Контроллер получает от пользователя запрос в определенном виде (запрос браузера, обращение к API, команда, все это разные группы контроллеров). Распарсив запрос передает его в модель для обработки.
    Модель содержит бизнес-логику, т.е. по-сути то, что должно делать ваше приложение, без привязки к способам обращения пользователей и способам вывода. Возможно будут вызываться модели работающие с БД, а может и не будут, это неважно, не превозносите БД как сверхсущность, это обычный инструмент, один из множества.
    Далее модель передает подготовленные для вывода данные в контроллер (в классической MVC сразу в представление), и контроллер передает их в нужное представление.
    Вот и все, простая схема, которая позволит отделить мух от котлет, создавать API, видоизменять вывод, не трогая основную логику. А работа с БД, совсем другой вопрос.
    Ответ написан
    Комментировать
  • Шаблоны проектирования - с чего начать знакомство?

    @Vitsliputsli
    Знаю что есть некие "шаблоны проектирования" - хочу познакомиться на практике - с какого именно начать?

    Ни с какого не нужно, просто прочитайте про них. Скорее всего вы уже использовали часть из них не зная об этом, т.к. это всего лишь удачные решения для типичных задач. Если изучили фреймворк, то в нем найдете много решений соответствующих шаблонам.
    Тут наоборот нужно, брать задачу и продумывая ее решение иметь ввиду что есть шаблоны проектирования.
    Ответ написан
    Комментировать
  • Зачем мне нужна модель, если я использую ORM?

    @Vitsliputsli
    В модели хранится бизнес-логика (она же domain), т.е. по-сути все самое интересное в модели. Вам нужно более внимательно изучить mvc
    Ответ написан
    Комментировать