Comments 9
Либо я чего-то не понял, либо нужно запостить сюда вот это название org.springframework.test
и вот это: AbstractTestNGSpringContextTests
Такое же есть для junit
и вот это: AbstractTestNGSpringContextTests
Такое же есть для junit
А как мне это помогает?
У меня есть проблема доступа к спринг бинам из не спринговых классов.
Я решаю её с помощью StaticContextHolder
Но как только я начинаю его использовать, возникает вопрос как тестировать классы, которые им пользуются
У меня есть проблема доступа к спринг бинам из не спринговых классов.
Я решаю её с помощью StaticContextHolder
Но как только я начинаю его использовать, возникает вопрос как тестировать классы, которые им пользуются
Мне кажется сама вот эта проблема доступа из не-спринг допущенной где-то в архитектуре ошибкой. Отсюда и комментарий о пакете.
Может быть, но как бы Вы решили эту проблему? Сделать все классы бинами? Передавать бины через цепочку конструкторов?
Пристально изучил бы логику приложения. Если у вас есть операционный класс, требующий доступ к бинам, то, похоже, вы где-то допустили ошибку. Этот сервис, сам по себе, должен бы создаваться инжектором (спрингом или что там у вас). Мне так кажется.
Может быть…
Но по моему такая ситуация может получиться вполне законно.
Что такое бин? Некий сервис. Он бин лишь по стольку поскольку мы используем спринг, так?
Так почему по дизайну один класс может вызывать синглетон сервиса, а другой — нет?
Но по моему такая ситуация может получиться вполне законно.
Что такое бин? Некий сервис. Он бин лишь по стольку поскольку мы используем спринг, так?
Так почему по дизайну один класс может вызывать синглетон сервиса, а другой — нет?
Я понимаю bean и service нескольк иначе в контексте нашей беседы. Раз уж мы говорим о spring, To bean — это любой объект, управляемый через spring. Service тут является неким классом, ответственным за логику приложения и, разумеется, ему неплохо бы быть бином, с точки зрения spring, иначе и возникает ваша проблема.
Вот этот класс из тестовой библиотеки, AbstractTestNGSpringContextTests как раз и показывает, что ваша проблема не чужда другим людям и они ее решают как раз передачей сервиса в управление спрингу.
Так вот, считаю, что приложение работающее в servlet/application контейнере должно само, в ответ на событие, создавать экземпляры и проводить и вставлять в них все необходимое с помощью InjectorHolder-ов либо средств платформы. Если вам приходится руками создавать класс, и в него впихивать знание о спринге — мне такой подход кажется ошибочным.
Декстопные приложения мне знакомы мало, но и там я бы продумал цепочку созданий и требований объектов так, чтобы получить на выходе полностью всем обеспеченный экземпляр.
Вот этот класс из тестовой библиотеки, AbstractTestNGSpringContextTests как раз и показывает, что ваша проблема не чужда другим людям и они ее решают как раз передачей сервиса в управление спрингу.
Так вот, считаю, что приложение работающее в servlet/application контейнере должно само, в ответ на событие, создавать экземпляры и проводить и вставлять в них все необходимое с помощью InjectorHolder-ов либо средств платформы. Если вам приходится руками создавать класс, и в него впихивать знание о спринге — мне такой подход кажется ошибочным.
Декстопные приложения мне знакомы мало, но и там я бы продумал цепочку созданий и требований объектов так, чтобы получить на выходе полностью всем обеспеченный экземпляр.
То, что Вы предлагаете, это " создавать экземпляры и проводить и вставлять в них все необходимое с помощью InjectorHolder-ов"
Это правильно, но что если у меня создается экземпляр класс A (через new), он создает экземпяр класс Б, он создает экземпляр класс С. Тут то мне и нужен сервис. Они не бины.
Я могу 1) Сделать их всех prototype beans и инжектить мой сервис в С. Работать будет, но делать обычные классы в большом числе прототайп бинами — видится излишним усложнением
2) Тянуть мой сервис через цепочку конструкторов — коряво как то
3) Сделать мой StaticContextHolder
Это правильно, но что если у меня создается экземпляр класс A (через new), он создает экземпяр класс Б, он создает экземпляр класс С. Тут то мне и нужен сервис. Они не бины.
Я могу 1) Сделать их всех prototype beans и инжектить мой сервис в С. Работать будет, но делать обычные классы в большом числе прототайп бинами — видится излишним усложнением
2) Тянуть мой сервис через цепочку конструкторов — коряво как то
3) Сделать мой StaticContextHolder
Sign up to leave a comment.
Создание spring beans из обычных классов и юнит тесты