Путаница в отношении сессионных компонентов, прокси-серверов и синглетонов в управляемом приложении Spring 3

Question

Похоже, что это базовый материал для Spring 101, но я не могу найти правильный способ сделать это.Ситуация выглядит следующим образом;в моем веб-приложении есть единственная точка входа, которая представляет собой контроллер, который обрабатывает пользователей, приходящих из внешней системы.Передача - это просто запрос POST с кучей связанной информации, относящейся к этому пользователю.Apon запись, мне нужно создать новый пользовательский бин и загрузить его с информацией этого пользователя.Кроме того, когда пользователь обращается к представлению, которое запускает некоторую службу, мне нужно, чтобы эта служба имела возможность доступа к соответствующему экземпляру пользовательского компонента.

Первый способ сделать это, который пришел в голову, - это создать UserManager.сервис, который создаст новый экземпляр User, заполнит его данными и затем зарегистрирует его в контейнере Spring с именем пользователя в качестве имени компонента.Затем, когда служба вызывается, служба выполняет что-то вроде Factory.getBean(username), чтобы найти соответствующий экземпляр User.Проблема, которую я вижу здесь, заключается в том, что я теряю связь между пользователем и принадлежащим им бином User.Кроме того, я бы хотел, чтобы пользователь не переносил компонент во время сеанса, если это вообще возможно.Это где я должен использовать Spring AOP и прокси?

Каков типичный шаблон Spring для решения ситуации такого типа?

Answer 1

Итак, сейчас много недель спустя (после того, как я задал этот вопрос), и, следовательно, мой уровень знаний рос в геометрической прогрессии, поэтому я подумал, что я мог бы также ответить на мой вопрос для любого, кто может найти его полезным (не говоря уже о вопросе).было не очень понятно для начала).

Основной ответ: используйте прокси.Так как синглтон создается только 1 раз, вы не можете ввести другой класс с более коротким сроком жизни, например.Объем сеанса.Для тех, кто нуждается в дополнительной информации, проверьте состояние с бобами без сохранения состояния.Более или менее то, что я в итоге сделал, это ... службы содержат код STATELESS для манипулирования данными (например, глаголы; RegisterUserSvc, AddPartSvc и т. Д.).Данные, которыми манипулируют эти сервисы, являются состоянием.Например, у каждого пользователя есть собственная копия своего собственного объекта данных, скажем, TodoListBean, который находится в разных состояниях для каждого пользователя.

Так как же сервис, например AddTodoItemService, манипулирует этими данными?Это где прокси вступает в игру.При создании экземпляра AddTodoItemService внедряется с прокси для TodoListBean вместо фактического объекта.Таким образом, когда службе требуется доступ к TodoListBean, контейнер будет обслуживать TodoListBean из сеанса текущего пользователя, и поэтому служба будет работать с правильным компонентом (в зависимости от того, какой пользователь вызвал службу) вместо выполнения чего-либоглупо, как если бы множество копий службы входило в сессию каждого пользователя.