본문 바로가기

웹 프로그래밍/스프링

 (30)
스프링 MVC(1) 원리 정리 프론트 컨트롤러 패턴 프론트 컨트롤러(수문장)가 하나로 클라이언트 요청에 맞는 컨트롤러를 찾아서 호출 공통 처리를 전담(나머지 컨트롤러는 서블릿 사용하지 않아도 됨) 스프링 MVC의 DispatcherServlet이 프론트 컨트롤러 패턴으로 구현되어 있음 어댑터 패턴 프론트 컨트롤러가 다양한 방식의 컨트롤러를 처리할수 있음 핸들러 어탭터: 프론트 컨트롤러와 컨트롤러(핸들러) 중간에 위치해서 어탭터 역할을 함 핸들러(컨트롤러): 컨트롤러인데 어댑터 덕분에 더 범주가 다양해짐 로그 출력(@Slf4j) SLF4J(인터페이스)의 구현체 Logback(구현체)를 사용 logging.level.hello.springmvc=debug (디폴트가 info) @RestController 원래 Controller는 뷰를 ..
웹 애플리케이션 이해 웹 서버 HTTP 기반 동작 정적 리소스 제공(HTML, CSS, JS, 이미지, 영상) 예) APACHE 웹 애플리케이션 서버(WAS - Web Application Server) HTTP 기반 동작 웹 서버 + 애플리케이션 로직(코드) 수행 동적 HTML, HTTP API(JSON) 서블릿, JSP, 스프링 MVC 예) Tomcat 웹 시스템 구성1 -WAS, DB 정적 리소스 때문에 핵심 비지니스 로직 수행이 어려울수 있음 웹 시스템 구성2 -WEB, WAS, DB 정적 리소스는 웹 서버가 처리 WAS는 비지니스 로직 전담 WAS나 DB 장애시 웹서버 에서 오류화면도 제고 가능 서블릿 WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체 호출 또 Response 객체에 담겨있는..
빈 스코프 스코프는 빈이 존재할수 있는 범위 싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프 프로토타입: 빈의 생성과 의존관계 주입(초기화 메서드포함)까지만 관여하고 클라이언트에 넘겨주고 더이상 관리하지 않음 프로토타입 스코프 -싱글톤은 스프링 컨테이너 생성시점에 스프링 빈을 등록하여 항상 같은 인스턴스의 스프링 빈을 반환 프로토타입은 요청마다 항상 새로운 인스턴스를 생성해서 반환 -> 관리 책임이 클라이언트로 넘어감 -> @PreDestory 같은 종료 메서드는 호출되지 않음 -싱글톤 빈과 함께 사용시에 의도대로 동작하지 않음 -싱글톤 빈에서 프로토타입 빈 사용하면 싱글톤 생성시점에 프로토타입이 주입되어 더이상 생성되지 않음 해결법 ObjectProvider 필요할때마다..
빈 생명주기(라이프사이클) 콜백 의존관계 주입이 끝나야 초기화를 할수 있을텐데 그 시점을 어떻게 알수 있을까? -스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려줌(종료도 마찬가지) 스프링 빈의 이벤트 라이프사이클(싱글톤) -스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 종료 스프링의 콜백 방법 -인터페이스 IntializionBean, DisposableBean (거의 사용하지 않음) -단점: 스프링 전용 인터페이스에 의존, 코드 수정이 불가한 외부 라이브러리에 적용불가 -빈 등록할때 초기화,소멸 메서드 지정( @Bean(initMethod = "init", destroyMethod = "close") -장점: 설정정보에..
스프링 빈 가져올때 팁 조회 대상 빈이 2개 이상일때 1.@Autowired 필드 명 매칭 -타입 매칭 -타입 매칭 결과가 2개 이상일때는 필드명, 파라미터명(첫소문자 주의) 으로 빈 이름 매칭 2.@Quilifier -> @Quilifier 이름끼리 매칭(추가 구분자), 단 모든 선언앞에 @Quilifier을 붙여 주어야함 3.@Primary 사용: 여러 빈 매칭되면 @Primary가 우선권을 가짐 @Quilifier가 @Primary보다 우선순위가 높음(구체적) 조회한 빈이 모두 필요할때 List, Map 사용 자동,수동의 올바른 기준 -트렌드는 자동을 선호 -업무 로직 빈(자동) -컨트롤러, 핵심 비지니스 로직, 데이터 계층의 로직을 처리하는 리포지토리등, 비지니스 요구사항을 개발할때 추가 및 변경 -단 다형성을 적극활용..
의존관계 자동 주입 다양한 의존관계 주입 방법 생성자 주입 -생성자 호출시점에 1번만 호출되는것이 보장 -불변, 필수(private final) 수정자 주입 -setter 주입 -선택 e.g. @Autowired(require = false) -변경 가능성이 있는 의존관계에 사용 필드 주입 -필드앞 에다가 @Autowired 를 직접함 -안티 패턴: 외부에서 변경이 불가능해서 테스트 어려움(쓰지 말것) 일반 메서드 주입 - 일반 메서드를 통해서 주입(setter와 유사) - 잘사용하지 않음 @Autowired는 스프링 컨테이너에 등록된 스프링 빈만 가능한 기능임
컴포넌트 스캔 컴포넌트 스캔 설정정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔 기능 제공 @ComponentScan이 붙은 Config클래스를 통해 @Component가 붙은 클래스를 스프링 빈 객체로 등록(이름은 첫글자가 소문자가됨) 의존관계도 자동으로 주입하는 @Autowired와 함께 쓰임(타입으로 찾아서 주입) 탐색위치와 기본 스캔 대상 basePackeage로 컴포넌트 스캔할 시작위치 지정(하위 포함) 지정하지 않으면 @ComponentScan이 붙은 클래스의 패키지를 시작위치 지정(디폴트가 관례)
싱글톤 패턴 왜 싱글톤? -(기존) 클라이언트가 요청할때마다 객체가 생성 -> 메모리 낭비 -해결책: 해당 객체를 한개만 생성하고 공유하도록 설계 -클래스의 인스턴스가 딱 1개만 생성되는것을 보장하는 디자인 패턴 -e.g. static 영역에 객체 instace를 미리하나 생성하고 getInstance()메서드를 통해서만 조회 -생성자를 private 막아서 new 키워드로 객체 인스터스가 생성되는것을 막음 -하나의 객체만을 쓰기 때문에 시스템 효율증가 -단점 - DIP 위반(클라이언트가 구체 클래스에 의존) e.g. 구체클래스.메서드() - OCP 위반 - 테스트하기 어려움(설정이 이미 끝남) - 유연성이 떨어짐 싱글톤 컨테이너 -싱글톤 패턴의 모든 문제점을 해결하면서 객체 인스턴스를 싱글톤으로 관리(스프링 빈 객..

티스토리툴바