Что в этой схеме надо поменять?выкинуть редис?
Что может пойти не так, что DTO от такой логики будет уже не DTO и какие могут быть проблемы?DTO - чисто инструмент переноса, в классическом ООП он выполняет роль сигнала для взаимодействия между абстрактными сущностями. По этому его задача хранить данные, а логика его построения должна быть отделена. Если у вас 10 дтошек, и что-то поменялось в логике построения, вы будете все десять штук менять, что уже выглядит странно и не очень логично. Напрашивается логичное решение - использовать фэктори, которая, в противовес дто, имеет только логику, и все манипуляции с данными сводятся в 1 место. Пишете фэктори, и на каждый источник у вас свой фабричный метод, а на выходе нужный дто.
Прикол в том, что если удалить физический файл, а запись в БД нет,то рано или поздно будешь сожалеть что написал кривой г-код. Это мы вроде как поняли.
Важно отметить, что доступ идёт на прямую к файлу, а не на сервер с запросом на файлНу да, это "редкий" случай. Важно понимать.
Возможно ли как-то это отследить и вывести ошибку об отсутствии файла (Ну и там не сервер кинуть запрос об удалении записи в БД и т.д. и т.п.)?Возможно. Достаточно добавить проверку на file_exists(), только пути надо указывать серверные (Важно понимать), так как поведение в случае запроса через веб адрес зависит от настроек окружения.
в одних пишут, что стат. методы нужны для обрaщения к методам класса без создания объектов, а другие пишут, что стат. методы нужны для обрaщения к стат. свойствам внутри клaсса.Оба утверждения в целом верны, второе больше относится например к private static переменным, то есть к сеттерам и геттерам. Разумеется из нестатических методов тоже можно получить к ним доступ, но только создав инстанс класса, в случае статик инстанс не требуется.
Не очень понятно о чем речь, где там про методы? Там про переменные же только?PHP использует модификаторы переменных static и global как ссылки.Если насчет свойств как ссылок все понятно, то что насчет методов как ссылок?