스프링 컨테이너 사용

결론 및 요약

스프링 컨테이너를 활용하여 독립 실행이 가능한 스프링 애플리케이션을 만들었습니다. 기존 Servlet 기반의 애플리케이션에서 직접 객체를 생성하고 관리하던 방식에서, 스프링 컨테이너를 통해 객체를 생성 및 관리하고 이를 필요할 때 가져와 사용하는 방식으로 전환했습니다. 이를 통해 더 유연하고 관리하기 쉬운 애플리케이션 구조를 구축할 수 있었습니다.

주요 내용 요약

1. 스프링 컨테이너와 Servlet 컨테이너의 역할 분리:

   • Servlet 컨테이너는 여전히 HTTP 요청을 처리하고 응답을 생성하는 역할을 맡지만, 객체(빈)의 생성과 관리는 스프링 컨테이너가 담당하게 되었습니다.
   • 기존에는 FrontController가 직접 객체를 생성하고 관리했지만, 이제는 스프링 컨테이너가 이 역할을 맡으며, 스프링 컨테이너에서 필요한 객체를 가져와 사용하게 됩니다.

2. ApplicationContext를 통한 빈 관리:

   • 스프링 컨테이너는 ApplicationContext를 통해 관리되며, 이 안에 등록된 빈 객체를 필요할 때 getBean() 메소드를 통해 가져옵니다.
   • 빈 등록은 registerBean() 메소드를 통해 이루어지며, 이 메소드로 클래스 정보를 등록하여 빈을 생성하고 이를 재사용할 수 있습니다.
   • 빈의 생성과 초기화는 refresh() 메소드를 사용하여 ApplicationContext를 초기화함으로써 자동으로 이루어집니다.

3. FrontController와의 통합:

   • FrontController는 기존과 동일하게 HTTP 요청을 처리하고, 스프링 컨테이너에서 필요한 객체(예: HelloController)를 가져와 해당 메소드를 호출하여 작업을 위임합니다.
   • 이후 응답 결과를 받아 웹응답으로 생성하는 역할은 변하지 않았습니다. 즉, 스프링 컨테이너로 전환하였지만, FrontController의 기본적인 요청 처리 구조는 유지되었습니다.

4. 테스트 및 검증:

   • 스프링 컨테이너로 전환한 후에도 기존 Servlet 애플리케이션처럼 제대로 동작하는지 테스트를 수행했습니다. HTTP 명령으로 요청을 보냈을 때, 상태 코드 200과 함께 적절한 응답이 잘 반환되었음을 확인했습니다.

결론:
스프링 컨테이너를 도입함으로써 객체의 생성과 관리를 더욱 효율적으로 처리하고, 기존의 Servlet 애플리케이션보다 유연하고 확장 가능한 구조를 만들었습니다. 이를 통해 개발자는 객체 생성과 관리를 신경 쓰지 않고 비즈니스 로직에 집중할 수 있게 되었으며, 애플리케이션의 구조가 더욱 체계적이고 유지보수가 용이해졌습니다.