Hyunebee

HTTP 요청을 통해 매핑된 URL이 호출되면 서블릿 컨테이너는 다음 메서드를 실행한다. protected void service(HttpServletRequest request, HttpServletResponse response) HttpServletRequest사용 HTTP 요청 메세지를 직접 파싱해서 사용해도 되지만 불편 HttpServletRequest는 이를 대신 파싱해주고 그 결과를 객체에 담아서 제공한다. START LINE HTTP 메소드 : request.getMethod() URL : request.getRequestURL(),request.getRequestURI() 쿼리 : request.getQueryString() 스트링 스키마,프로토콜 : request.getScheme() ..

웹서버 HTTP 기반으로 동작 정적 리소스 제공 ex)NGINX, APACHE 웹 애플리케이션 서버(WAS) 웹 서버 기능을 포함 + (정적 리소스) 프로그램 코드를 실행해서 애플리케이션 로직 수행 동적 HTML, HTTP API servlet jsp spring MVC ex)tomcat, jetty 웹서버 vs 웹 애플리케이션 서버 1. 둘의 경계가 모호함 둘다 서로의 기능을 조금식 제공함 2. 자바는 서블릿 컨테이너 기능을 제공하면 WAS 웹 시스템의 구성 -> 간단하게 WAS , DB로 구현할 수 있다. 하지만 WAS가 너무 많은 역할을 담당 서버 과부하 우려가 있다. WAS 장애시 오류 화면도 노출 불가능 웹 시스템의 구성 -> WEB WAS DB 정적 리소스는 웹서버가 처리 웹 서버는 애플리케이..

스프링 빈의 이벤트 라이프 사이클 스프링 컨테이너 생성 -> 스프링 빈생성 -> 의존 관계 주입 -> 초기화콜백 ->사용 -> 소멸전 콜백->스프링 종료 스프링 빈이 생성되고 의존 관계를 주입한뒤 사용을 해야한다 이때 완료를 알려주는게 초기화 콜백이다. 스프링은 크게 3가지 방법으로 생명주기 콜백을 지원한다. 1.인터페이스 InitializingBean, DisposableBean 해당 인터페이스 메소드를 오버라이딩해서 사용 2.설정 정보에 초기화메소드, 종료 메서드 지정 빈에서 정의한 메소드의 이름을 추가해준다. 3. @PostConstruct, @PreDestory(권장) 스프링 기술이 아니라 자바표준기술이다. https://www.inflearn.com/course/%EC%8A%A4%ED%94%84..

다양한 의존 관계 주입방법 1. 생성자 주입 생성자 호출시점에 딱 1번만 호출되는것을 보장한다. 불변 필수 의존관계에 사용한다. 2. 세터주입 변경, 선택 가능성이 있는 의존 관계에 사용 3. 필드주입 사용하지 말자(테스트가 어렵고, DI프레임워크가 없다면 사용할 수 도 없다.) 4. 메서드 주입 한번에 여러 필드를 주입 받을 수 있다. 빈 우선 순위 결정 @Qualifier -> @Qualifier("mainDiscountPolicy") -> public DiscountPolicy setDiscountPolicy(@Qualifier("mainDiscountPolicy") 이렇게 서로 매칭 시켜서 사용한다. 만약 해당 빈이름이 없다면 오류 발생 @Primary 해당 어노테이션이 붙어있는것이 우선순위를 가..

@CompoenetScan은 @Component가 붙은 모든 클래스를 스프링 빈으로 등록한다. 이때 스프링 빈의 기본 이름은 클래스명을 사용하되 맨 앞글자만 소문자를 사용한다. @Autowired 의존관계 자동주입 생성자에 @Autowired를 지정하면, 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입한다. 이때 기본 조회 전략은 타입이 같은 빈을 찾아서 주입한다. 이렇게 자동으로 의존관계를 주입하다보면 같은 빈 이름을 등록하면 어떻게 될까? 1.자동 빈 등록 vs 자동 빈 등록 컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록되는데, 그 이름이 같은 경우 스프링은 오류를 발생시킨다. ConflictingBeanDefinitionException 예외 발생 2.자동 빈 등록 vs 수동 빈 등록 이..

웹 애플리케이션과 싱글톤 이렇게 사용할시 사용자가 호출할 때마다 객체가 생성된다. -> 메모리 낭비 이렇게 사용함으로써 동일한 객체에만 접근할 수 있도록 설계를 해줄 수 있다. --> 스프링이 제공을 해준다. 싱글톤 패턴 문제점 1. 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다. 2. 의존관계상 클라이언트가 구체 클래스에 의존한다. 3. DIP를 위반한다. 4. 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다. 5. 테스트하기 어렵다. 6. 내부 속성을 변경하거나 초기화 하기 어렵다. 7. private 생성자로 자식 클래스를 만들기 어렵다. 8. 결론적으로 유연성이 떨어진다. 하지만 스프링은 이러한 단점을 해결해준다. 스프링 싱글톤 방식의 주의점 싱글톤 방식은 여러 클라이언..

스프링 컨테이너는 @Configuration붙은 것은 구성 정보로 사용한다. @Bean이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. @Bean에 적힌 메서드의 명으로 컨테이너에 등록한다. 등록된 빈은 applicationContext.getBean()으로 찾아서 사용할 수 있다. ApplicationContext는 인터페이스 이며 보통 스프링 컨테이너라고 한다. 우리는 new 키워드를 사용해서 AppConfig.class를 구성정보로 지정해서 사용한다. Spring Container에서 생성된 빈들은 서로의 의존관계를 설정한다. 스프링 빈 조회 - 기본 getBean(빈이름, 타입) getBean(타입) if 조회 대상이 빈에 없으면 예외(NoSuchBeanDefinitio..

새로운 할인 정책 이 코드는 문제점이있다. 다형성도 활용하고 인터페이스와 구현을 분리했다. 하지만 OrderServiceImpl은 DiscountPolicy와 구현체인 FixDiscountPolicy,RateDiscountPolicy에도 의존하고 있다. -> DIP위반 또한 기능을 확장해서 변경하면 클라이언트의 코드가 변경된다. -> OCP위반 이렇게 사용할 경우 구연체가 없어서 오류가 발생하게 된다. 관심사를 분리하자 구현 객체를 생성하고 연결하는 책임을 가지는 별도의 클래스를 만들어서 사용하자 이것이 AppConfig이다. 이런식으로 생성자를 주입해준다. 그러면 생성자가 생성되는 시점에 기능이 주입되게 된다. 그렇게 된다면 AppConfig만의 변경으로 기존코드의 변경없이 기능을 확장시킬 수 있다. ..