기존의 Servlet, JSP 같은 경우 너무 많은 역할을 수행한다. 비즈니스 로직과 뷰 렌더링을 다 처리하게 되면 너무 많은 역할을 하고 결과적으로 유지보수가 어려워진다. 따라서 각각의 역할을 나눠서 코드를 작성하는 MVC 패턴을 사용하게 된다. * 사실 가장 중요한 이유는 UI를 변경하는 일과 비즈니스 로직을 변경하는 일은 다른일이기 때문에 하나의 코드로 관리해서는 안된다. 컨트롤러 : HTTP 요청을 받아서 파라미터를 검증하고 비즈니스 로직을 실행하고 뷰에 전달할 결과 데이터를 조회후 모델에 담는다. 모델 : 뷰에 출력할 데이터를 담아둔다. 뷰 : 모델에 담겨있는 데이터를 사용해서 화면을 그리는 일에 집중한다.
웹 시스템 구성 정적 리소스는 웹 서버가 처리 하고 애플리케이션 로직같은 동적인 처리가 필요하면 웹 애플리케이션 서버에 요청을 위임 하게 되는 형식으로 많이 설계가 되고 있다. 또 이런방식의 설계는 효율적인 리소스를 관리하는데 많은 도움이 된다. 정적 리소스가 많이 사용되면 웹 서버를 증설하고 애플리케이션 리소스가 많이 사용되면 웹 애플리케이션 서버를 증설하면 된다. 또 이러한 설계는 웹 애플리케이션 서버가 오류를 발생했을 경우 웹 서버에서 오류 화면을 제공할 수 있다. (기본적으로 정적 리소스를 제공하는 웹 서버는 오류의 확률이 적다) Servlet 서블릿 HTTP 요청이 오면 웹 애플리케이션 서버는 Request, Response 객체를 새로 만들어서 서블릿 객체를 호출한다. 개발자는 Request ..
스프링 빈의 이벤트 라이프 사이클(Singleton Scope) 스프링 컨테이너 생성 ▶ 스프링 빈 생성 ▶ 의존관계 주입 ▶ 초기화 콜백 ▶ 사용 ▶ 소멸전 콜백 ▶ 스프링 종료 초기화 콜백: 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출 소멸전 콜백: 빈이 소멸되기 직전에 호출 스프링의 콜백 지원 방법 3가지 인터페이스(InitializingBean, DisposableBean) 인터페이스를 상속 받아서 생성과 소멸의 시기에 호출을 하는 방법. 이 인터페이스는 스프링 전용 인터페이스이기 때문에 스프링 전용 인터페이스에 의존한다. 초기화, 소멸 메서드의 이름을 변경할 수 없고 내가 코드를 고칠 수 없는 외부 라이브러리에 적용을 할 수 없다. → 예전에 사용하던 방식으로 거의 사용하지 않는다. 빈..
결론부터 말하면 편리한 자동 기능을 기본으로 사용하자. 스프링이 나오고 나서 점점 자동화 되는 기능을 선호하는 추세이고 설정 정보를 계층에 맞추어 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원한다. 번거로움을 줄일 수 있는 이런 과정을 선호하는 이유는 편리함도 있지만 관리할 빈이 많아서 설정 정보가 커지면 설정 정보를 관리하는 것 자체가 부담이 될 수 있기 때문이다. 그렇다면 수동 빈 등록은 언제 사용하면 좋을까? 업무 로직과 기술 지원 로직으로 나누어서 생각을 해보자. 업무 로직 빈 : 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리등이 모두 업무 로직이다. 보통 비지니스 요구사항을 개발할 때 추가되거나 변경된다. → 숫자들이 엄청 중..
의존관계의 주입방법은 크게 4가지 존재. 생성자 주입 수정자 주입(setter 주입) 필드 주입 일반 메서드 주입 생성자 주입 생성자를 통해서 의존 관계를 주입 받는 방법이다. 생성자 호출 시점에서 딱 1번만 호출되는 것이 보장된다. 불변, 필수 의존관계에 사용된다. 한번 호출이 되면 바뀌면 안된다. 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입 된다. (요즘에는 이렇게 사용한다는데 흠 나는 명시하는게 더 좋을것 같음.) 수정자 주입(setter 주입) setter라 불리는 필드의 값을 변경하는 수정자 메서드를 통해서 의존관계를 주입하는 방법이다. 선택, 변경 가능성이 있는 의존관계에 사용 JAVA Bean Property 규약의 수정자 메서드 방식을 사용하는 방법이다. @Autow..
BeanFactory 스프링 컨테이너의 최상위 인터페이스 스프링 빈을 관리하고 조회하는 역할 담당. getBean() 제공 ApplicationContext BeanFactory 기능을 모두 상속받아서 제공. ApplicationContext 가 상속받는 인터페이스 BeanFactory MessageSource : 메세지 소스를 활용한 국제화 기능 EnvironmentCapable : 환경 변수 (로컬, 개발, 운영등을 구분해서 처리) ApplicationEventPublisher : 이벤트를 발행하고 구독하는 모델을 편리하게 지원 ResourceLoader : 파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회 대부분 BeanFactory를 직접적으로 사용할 일은 거의 없고 부가 기능이 포함된 Ap..
의존관계 주입 DI(Dependency Injection) 행위의 동작을 나타내는 클래스는 실제 어떤 구현 객체가 사용될 지 모르도록 인터페이스에 의존해야 한다. 의존관계는 정적인 클래스 의존 관계와, 실행 시점에 결정되는 동적인 객체(인스턴스) 의존 관계 둘을 분리해서 생각해야 한다. 정적 클래스 의존관계 클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단할 수 있다. 클래스 다이어 그램을 살펴보면 쉽게 알 수 있다. 하지만 이러한 클래스 의존관계만으로는 실제 어떤 객체가 주입이 될지 알 수 가 없다. 동적 클래스 의존관계 애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결 되는 것을 의존관계 주입이라 한다. ..
