이모저모

타임리프, Thymeleaf 특징 1. 서버 사이트 HTML 렌더링, SSR - 백엔드 서버에서 HTML을 동적으로 렌더링 하는 용도로 사용 2. 네츄럴 템플릿 : 순수 HTML을 유지하며 뷰 템플릿으로 사용할 수 있는 특징 - 순수 HTML을 최대한 유지하는 특징 - 웹 브라우저에서 파일을 직접 열어도 확인 가능하며, 서버를 통해 동적으로 변경된 결과 확인 가능 3. 스프링 통합 지원 - 스프링과 통합하여 여러 기능을 지원한다. 선언 텍스트 - text, utext 텍스트를 출력하는 기능 - 태그 없이 출력하는 기능 - [[${data}]] HTML 엔티티 웹 브라우저는 "

요구사항 분석 상품 도메인 모델 - 상품 ID, 상품명, 가격, 수량 상품 관리 기능 - 상품 목록(조회), 상품 상세, 상품 등록(C), 상품 수정(U) 타임리프 타임리프 선언 타임리프 핵심 th:xxx 가 붙은 부분은 서버사이드에서 렌더링되고, 기존 것을 대체된다. 붙지 않은 것은 html의 속성이 적용된다. html을 유지하면서 템플릿 기능을 할 수 있다. 타임리프 문법 속성 변경 - th:href="@{/css/bootstrap.min.css}", href="" 이 변경된다. 링크 표현 식 - th:href="@{/css/bootstrap.min.css}", url링크를 @{} 방식으로 사용한다. 리터럴 대체 - |...|, "와 '를 신경써야 했던 것을 "와 |로 사용한다. 반복 출력 - th:..

HTTP 요청 - 쿼리 파라미터, HTML FORM, HTTP 메시지 사용/META-INF/resources 1. GET - 쿼리 파라미터 /url?username=hello&age=20 메시지 바디 없이, URL의 쿼리 파라미터에 데이터를 포함해서 전달 예) 검색, 필터, 페이징등에서 많이 사용하는 방식 2. POST - HTML Form content-type: application/x-www-form-urlencoded 메시지 바디에 쿼리 파리미터 형식으로 전달 username=hello&age=20 예) 회원 가입, 상품 주문, HTML Form 사용 3. HTTP message body에 데이터를 직접 담아서 요청 HTTP API에서 주로 사용, JSON, XML, TEXT 데이터 형식은 주로 ..

프톤트 컨트롤러 패턴 이전의 컨트롤러의 역할을 보면 중복되는 코드가 많다. (뷰로 이동과 같은) 그래서 컨트롤러에 접근하기 전, 프론트 컨트롤러를 통해 공통 처리를 하고 온다. 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 된다. v1 구현 - 프론트 컨트롤러 도입 urlPatterns = /fron-controller/v1의 하위 경로들은 모두 이 서블릿을 접근하게 된다. controllerMap에 저장된 URI를 통해 controller 변수에 각 컨트롤러가 호출된다. -> 중복되는 코드를 줄일 수 있었다. JSP는 이전의 코드를 그대로 사용한다. v2 구현 - 뷰 분리 뷰(jsp)로 이동하기 위해 모든 컨트롤러에 아래와 같은 코드가 반복된다. String viewPath = "..

서블릿 서블릿 -> WAS에 서블릿 코드를 클래스 파일로 빌드해서, WAS에서 실행 HttpServlet을 상속받아 HttpServletRequest 객체와 HttpServletResponse 객체를 service 메서드로 관리한다. HttpServletRequest HTTP 요청 메시지를 직접 파싱해도 되지만, 불편하고 어렵다. 서블릿은 이를 파싱해주고, 결과를 HttpServletRequest 객체에 담아서 제공한다. 역할 HTTP 메서드, URL, 쿼리 스트링, message body와 같은 정보를 파싱 임시 저장소 기능 - 저장 .setAttribute(), 조회 .getAttribute 세션 관리 기능 - .getSession HttpServletRequest의 정보 조회 start-line 조..

WAS(Web Application Server) 와 Web Server Web Server HTTP기반으로 동작 정적 리소스 제공 NGINX,APACHE .. WAS HTTP기반으로 동작 웹 서버 기능 + 프로그램 코드를 실행하여 애플리케이션 로직 수행 -> 사용자에 따른 동적 페이지 제공 동적 HTML, HTTP API, 서블릿, JSP, 스프링 MVC Tomcat ... 둘의 가장 큰 차이는 웹 서버는 정적 리소스를, WAS는 애플리케이션 로직을 제공하는 부분이다. -> WAS는 애플리케이션 코드를 실행하는데 특화 웹 시스템의 구성 웹 시스템은 WAS, DB로 구성할 수 있다. 하지만, WAS가 부담하는 영역이 커지고(정적 리소스까지 제공해야 함), 장애 발생 때 대응이 어렵다. -> WAS가 전..

빈 생명주기 콜백이란 DB Connection pool - 애플리케이션 서버와 DB 서버를 연결하여 미리 connection을 생성해 두는 것 (자세한 것 아님, 간단한 요약) DB connection pool이나 네트워크 소켓같이 애플리케이션 종료 시점에 연결을 모두 종료하려는 작업을 할 때, 객체의 초기화와 종료작업이 필요함 스프링 빈은 객체 생성 후 의존관계 주입이라는 사이클을 갖는다( 생성자 주입은 예외 ) 즉, 의존관계 주입이 끝나야 데이터를 사용할 수 있는 준비가 완료되는 것이다. 의존관계 주입이 완료된 시점을 알 수 있는 방법이 바로 콜백이다. 스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸 전 콜백 -> 스프링 종료( 이는 스프링 전용 ..

의존관계 주입 방법의 종류 1. 생성자 주입 생성자를 통해 의존관계를 주입받는다. 생성자 호출 시점에 단 1번 호출되는 것이 보장된다. 불변, 필수 의존관계에서 사용한다. -> 수정할 수 있는 기능을 추가하지 않는 것이 중요 생성자가 하나인 경우 @Autowired를 사용하지 않아도 스프링 컨테이너가 자동으로 의존관계 주입한다. 2. 수정자(setter) 주입 setter로 필드의 값을 변경하는 수정자 메서드를 통해 의존관계 주입 ( 메서드명은 set필드명 ) 선택, 변경가능 의존관계에서 사용한다. -> 호출하여 변경할 수 있는 경우 +) 자바빈 프로퍼티 규약 -> 필드의 값을 직접 변경하지 않고 get, set 메서드를 통해 읽고 수정하는 내용 3. 필드 주입 필드에 바로 의존관계를 주입시키는 방법 외..

컴포넌트 스캔과 의존관계 자동 주입 이전까지 스프링 빈을 등록하려 했다 - @Bean을 통해 설정 정보에 직접 등록 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 @ComponentScan 기능을 제공한다. 컴포넌트 스캔은 @Component이 붙은 클래스를 스캔해서 스프링 빈으로 등록한다. +) @Configuration이 붙은 설정 정보도 자동 등록이 됨, 충돌을 조심하자 단, 스프링 빈 이름은 클래스 이름의 첫 문자를 소문자로 변경하여 사용한다. ( AddPrice -> addPrice ) 또한, 의존관계를 자동으로 주입해주는 @Autowired 기능도 제공한다. 디폴트는 스프링 컨테이너가 타입이 같은 빈을 찾아서 주입한다. 컴포넌트 스캔의 탐색 위치와 기본 스캔 대상 컴포넌트 스캔의 ..

웹 애플리케이션과 싱글톤 웹 애플리케이션은 보통 여러 고객이 동시 요청을 요구함 -> 요청마다 객체를 생성해야 함 -> 좋지 않은 방법.. 해결 방안? - 해당 객체를 1개만 생성하고, 생성된 객체를 공유하도록 설계한다. ==> 싱글톤 패턴 싱글톤 패턴( Singleton Pattern ) 클래스의 인스턴스가 1개만 생성되는 것을 보장하는 디자인 패턴 어떻게 보장? - private 생성자를 사용해 외부에서 임의로 new 키워드 사용하지 못하게 하여 보장 위의 코드는 객체를 미리 생성해두는 단순하고 안전한 방법, 다른 여러 싱글톤 패턴도 존재한다. 장점만 존재하는가? 문제점은? 싱글톤 패턴을 구현하기 위한 코드가 많이 들어간다. 의존관계상 클라이언트가 구체 클래스에 의존한다. - DIP위반 클라이언트가 ..