Сессия извлекается в SF2 через объект Request. Хм, это становится проблематичным, когда рассматривается какая-то архитектура - в тех случаях, когда доступ к сеанс-варам необходим из службы.Сложная и запрашивающая дилемма объектов
Возможно, я не совсем прав в этом вопросе? (Надеюсь на это).
Очевидно, что каждый запрос от пользователя через веб-браузер является a Request. Поэтому, пока мы используем действия контроллера в стандартном SF2, у нас есть Request. Но должен ли мы передать объект Request на любой сервис, который нам нужен?
Передача объекта запроса всем службам, которым требуются их методы для запуска (например, сохранение информации, проверка настроек, установка фильтров для отображения данных и т. Д.), А в некоторых более крупных приложениях их довольно много!), Потому что это может понадобиться из-за зависимых услуг, кажется мне очень глупой идеей. Он также нарушает «S» в рекомендации S.O.L.I.D. для ООП.
Так я пришел к выводу, мне нужно либо:
Пропустите запрос OBJ для многих услуг только потому, что зависимая служба может потребность некоторые данные из него (т.е. сломана «S ", как указано выше)
Извлеките и обработайте данные из запроса каждый раз, когда мне нужно в каждом действии контроллера (например, дублирование кода) - в этом случае я не передаю запрос obj, но предварительно подготовлю все необходимые данные - но Я должен сделать это тогда во многих методы действий практически во всех контроллерах (получение/обработке данных из запроса только простой вызов для другой службы, но тогда это не централизовано)
Я ставлю этот вопрос, потому что я, например, следующую проблему:
Я использую те же фильтры для всех разных данных (из разных источников данных) на всей странице.
Фильтры могут быть включены и отключены - и они должны помнить, для всех страниц за одну сессию
я решил, что спасение «ОТКЛ» фильтры для сеанса, вероятно, лучший подход (поскольку по умолчанию все данные следует рассматривать, то есть все фильтры должны быть в состоянии «включить»)
3-я точка - сохранение данных (фильтры) для сеанса - это то, что делает проблемы в SF2, как описано выше. Для отображения отфильтрованных данных на странице мне нужен доступ к сеансу и, следовательно, доступ к объекту Request. И это означает, что я испытываю трудности с сохранением «S» в SOLID, из-за того, что зависимость от метода сервиса всегда передается ему.
Есть ли другое, лучшее решение, чем упомянутое 2 (т. Е. Одно, разбивающее SOLID или два, дублирование кода)?