스프링이 관리하지 않는 응용 프로그램 내 깊은 곳에서 스프링 구성 요소를 액세스하는 가장 좋은 방법은 무엇입니까?깊은 주입 - 스프링
예를 들어 일부 @Controllers가 있다고 가정 해보십시오. 봄에 의해 관리되지 않는 POJO를 통한 추상화 계층을 통해, @Controller는 @Service가 주입되어야하는 POJO를 사용하여 끝날 수 있습니다.
하나의 옵션은 모든 레이어를 봄 구성 요소로 만드는 것이지만 스프링이 나를 도와주기 위해 내 디자인을 해킹하고있는 것처럼 보입니다. 나는 모든 일을 @Autowire해야만하면 깨끗하게 될 수없는 복잡한 일들이있다. 또 다른 옵션은 저수준 클래스에 수동으로 구성 요소를 주입하는 것이지만 이것이 가능한지 또는 올바른 해결책인지는 잘 모르겠습니다.
원래 질문에 답하는 정신에서, 당신은 당신이 당신의 저수준 비 스프링 클래스가 ApplicationContext에 대한 액세스를 얻기 위해 ApplicationContextAware를 구현하고, ApplicationContext를 사용하여 원하는 스프링 빈에 접근 할 수 있다고 말할 것입니다. (sample code을 찾으려면 "스프링 애플리케이션 컨텍스트 인식"에 대한 Google 검색을 참조하십시오.)
그러나 큰 그림을 여기서 말하려는 정신으로 처음부터이 문제에 몇 가지 문제가 있습니다. 우선, 저수준 구성 요소에 주입하려는 고수준 구성 요소가있는 것처럼 들리지만 일반적으로 디자인이 다른 방식으로 이루어지기를 원합니다. 또한, 지적했듯이, "서로 떨어져있는"것들은 아마도 서로에 의존해서는 안됩니다. 이러한 점을 염두에두고 디자인을 개선하면이 경우에 도움이됩니다.
이미 사용중인 프레임 워크를 최대한 활용하기 위해 모든 레이어를 스프링 구성 요소로 만들지는 않을 것입니다. DI 프레임 워크를 사용하려면 일반적으로 전체 프레임 워크를 사용하여 DI 프레임 워크를 만드는 것이 좋습니다. 그리고 전역에서 @Inject (Java EE 표준)를 사용하고 범위 컨트롤과 함께 DI 프레임 워크 배선을 사용하는 깔끔한 디자인은 실제로 "새로운"모든 것을하는 것보다 깨끗합니다.
아마 어디서나 DI 프레임 워크를 사용하고 싶습니다. 어떤 것들이 만들어 지는지에 대한 믹싱/매칭에 대한 당신의 요지를 보았습니다 만, 모든 어플리케이션은 스프링 구성 요소 일 필요가 없으므로 그렇게 강제하는 것은 잘못된 것처럼 보입니다. 프레임 워크가 도움이 될 것입니다. 원래 게시물을 명확히하려고 노력했습니다. 저수준 클래스는이를 사용하는 스프링 구성 요소에 의존하지 않습니다. 그것은 높은 수준의 컨트롤러가 모르는 다른 스프링 구성 요소에 달려 있습니다. –
공유 한 샘플 코드에서 메서드를 사용하기로 결정했습니다. 내가 너무 봄에 관리되는 디자인을 강요하려고하면 너무 부자연스러워지는 다른 것들이 너무 많습니다. 감사! –
내 직관은 물건들이 서로 떨어져서 "서로 떨어져서"있다면 서로에 의존해서는 안된다는 것입니다. – rolve
@rolve - 나는 그 의견을 이해할 지 모르겠다.하지만 내 대답은 "그렇지 않다"고 생각한다. LowLevelHelper POJO는 \ @Service 클래스를 사용하여 DB에 액세스해야합니다. 그 위의 레이어에 의존하지 않습니다. –
@rolve - LowLevelHelper POJO가 사용해야하는 스프링 구성 요소가 "레이어"의 맨 위에있는 동일한 구성 요소가 아니라는 혼란을 깨닫고 있습니다. 나는 이것을 게시물에서 클리어 할 것입니다. –