프로그래밍 공방

Thymeleaf 타임리프 사용 선언 속성 변경 타임리프를 사용하여 기존 속성의 값을 변경할 때는 위와 같이 th:를 붙인 해당 속성을 하나 더 생성해주면 된다 * HTML을 그대로 볼 때는 기존 속성이 사용되고(th: 는 HTML이 모르는 문법이므로 무시된다), 뷰 템플릿을 거치면 th: 의 값이 기존 속성을 대체하면서 동적으로 변경할 수 있게 된다 * 순수 HTML을 그대로 유지하면서 뷰 템플릿도 사용할 수 있는 타임리프의 특징을 네츄럴 템플릿 (natural templates)이라 한다 * 뷰 템플릿 영역 : /resources/templates 변수 표현식 - ${ ... } 10000 Model에 포함된 값이나, 타임리프 변수로 선언한 값을 조회할 수 있다(프로퍼티 접근법을 사용 / item.g..

참고 * Jar을 사용하면 항상 내장 서버(톰캣등)을 사용하고, webapp 경로도 사용하지 않는다(내장 서버 사용에 최적화 되어 있는 기능) War를 사용하면 내장 서버도 사용 가능하지만, 주로 외부 서버에 배포하는 목적으로 사용 * Jar를 사용하면 /resources/static 위치에 index.html 파일을 두면 Welcome 페이지로 처리해준다 (스프링 부트가 지원하는 정적 컨텐츠 위치) @RequestMapping @RestController @RequestMapping("/test") public class MappingCcontroller { // method 설정을 통해 특정 HTTP 메서드 요청만 허용하도록 할 수 있다 // @RequestMapping("/hello", method..

스프링 MVC 구조 이전에 포스팅한 글의 MVC 구조와 비교하면 아래 내용들이 변경되었다 - FrontController -> DispatcherServlet - handlerMappingMap -> HandlerMapping - MyHandlerAdapter -> HandlerAdapter - ModelView -> ModelAndView - viewResolver -> ViewResolver - MyView -> View DispatcherServlet 구조 스프링 MVC도 Front Controller 패턴으로 구현되어 있고 스프링 MVC의 Front Controller가 DispatcherServlet 이다 DispatcherServlet도 부모 클래스에서 HttpServlet을 상속 받고 서블릿..

프론트 컨트롤러 패턴 클라이언트들이 각 Controller를 호출하는게 아니라 Front Controller에 요청을 보내고 Front Controller가 각 요청에 맞는 컨트롤러를 찾아서 호출하는 패턴 Front Controller 패턴 특징 프론트 컨트롤러 서블릿 하나로 클라이언트의 요청을 받음 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출 공통 처리 가능 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨 * 스프링 웹 MVC의 핵심도 바로 Front Controller 이다(DispatcherServlet이 FrontController 패턴으로 구현되어 있음) 프론트 컨트롤러의 단계적 도입 프론트 컨트롤러 도입 - V1 기존 코드를 최대한 유지하면서 프론트 컨트롤러 구..

Servlet 패턴 Servlet을 통해서 request를 받고 HttpServletResponse에 Html을 담아 응답하는 방식 단점 서블릿과 자바 코드만으로 HTML을 만드는 경우 아래와 같이 서블릿 덕분에 동적으로 원하는 HTML을 만들 수 있다 @WebServlet(name = "userSaveServlet", urlPatterns = "/servlet/users/save") public class UserSaveServlet extends HttpServlet { private UserRepository userRepository = UserRepository.getInstance(); @Override protected void service(HttpServletRequest request,..

Servlet / 서블릿 클라이언트의 요청을 받아 웹페이지를 동적으로 생성하여 응답하는 서버측 프로그램 * 서블릿은 아래 작업들을 대신해서 처리해준다 - 서버 TCP/IP 연결 대기, 소켓 연결 - 웹 브라우저가 생성한 요청 HTTP 메시지 파싱 - HTTP 응답 메시지 생성 - TCP/IP에 응답 전달, 소켓 종료 (비즈니스 로직을 제외한 모든 프로세스들을 처리) @ServletComponentScan 스프링 부트에서 서블릿을 직접 등록해서 사용할 수 있도록 지원하는 어노테이션 (@WebServlet 등의 어노테이션을 스캔하여 서블릿 컨테이너에 등록한다) @WebServlet(name = "tempServlet", urlPatterns = "/hello") - name : 서블릿 이름 - urlPatt..

자바 웹 기술 역사 과거 기술 서블릿 - 1997 - HTML 생성이 어려움 JSP - 1999 - HTML 생성은 편리하지만, 비즈니스 로직까지 너무 많은 역할을 담당 서블릿, JSP 조합 MVC 패턴 사용 - 모델, 뷰, 컨트롤러로 역할을 나누어 개발 MVC 프레임워크 춘추 전국 시대 - 2000년 초 ~ 2010년 초 - MVC 패턴 자동화, 복잡한 웹 기술을 편리하게 사용할 수 있는 다양한 기능 지원 - 스트럿츠, 웹워크, 스프링 MVC(과거 버전) annotation 기반의 스프링 MVC 등장 - @Controller - MVC 프레임워크의 춘추 전국 시대 마무리 스프링 부트의 등장 - 스프링 부트는 서버를 내장 - 과거에는 서버에 WAS를 직접 설치하고, 소스는 War 파일을 만들어서 설치한 ..

정적 리소스 - 고정된 HTML 파일, CSS, JS, 이미지, 영상 등을 제공 - 주로 웹 브라우저 HTML 페이지 - 동적으로 필요한 HTML 파일을 생성해서 전달 - 웹 브라우저 : HTML 해석 HTTP API - HTML이 아니라 데이터를 전달 - 주로 JSON 형식 사용 - 다양한 시스템에서 호출 - 데이터만 주고 받음, UI 화면이 필요하면, 클라이언트가 별도 처리 - 앱, 웹 클라이언트, 서버 to 서버 - UI 클라이언트 접점 - 앱 클라이언트 - 웹 브라우저에서 자바스크립트를 통한 HTTP API 호출 - React, Vue.js 같은 웹 클라이언트 - 서버 to 서버 - 주문 서버 -> 결제 서버 - 기업간 데이터 통신 서버 사이드 렌더링, 클라이언트 사이드 렌더링 SSR(서버 사이드..

쓰레드 - 애플리케이션 코드를 하나하나 순차적으로 실행하는 것은 쓰레드 - 자바 메인 메서드를 처음 실행하면 main이라는 이름의 쓰레드가 실행 - 쓰레드가 없다면 자바 애플리케이션 실행이 불가능 - 쓰레드는 한번에 하나의 코드 라인만 수행 - 동시 처리가 필요하면 쓰레드를 추가로 생성 단일 요청 - 쓰레드 하나 사용 쓰레드1이 쉬고 있다가 요청1이 연결에 들어오면 쓰레드1을 할당하고 쓰레드 1을 가지고 servlet을 호출한다 쓰레드1은 비즈니스 로직을 수행 후 요청1에 대한 응답1을 수행하고 쓰레드1은 다시 휴식으로 들어간다 다중 요청 - 쓰레드 하나 사용 쓰레드 1이 쉬고 있다가 요청1이 연결에 들어오면 쓰레드 1을 할당하고 쓰레드1을 가지고 servlet을 호출한다 그러나 처리가 지연되고 이때, ..

Servlet 클라이언트의 요청을 받아 웹페이지를 동적으로 생성하여 응답하는 서버측 프로그램 웹 애플리케이션 서버를 직접 구현한다면 해야할 일 1. 서버 TCP/IP 연결 대기, 소켓 연결 2. 웹 브라우저가 생성한 요청 HTTP 메시지 파싱해서 읽기 3. 파싱한 데이터를 분석해서 필요한(저장) 프로세스 실행 4. 비즈니스 로직 실행 - 데이터베이스에 저장 요청 5. HTTP 응답 메시지 생성 시작 - HTTP 시작 라인 생성 - Header 생성 - 메시지 바디에 HTML 생성 후 입력 6. TCP/IP에 응답 전달, 소켓 종료 서블릿을 지원하는 WAS를 사용한다면 해야할 일 1. 비즈니스 로직 실행 - 데이터베이스에 저장 요청 서블릿 @WebServlet(name = "helloServlet", ur..