타임리프 사용 선언 속성 변경 - th:href th:href="@{/css/bootstrap.min.css}" href="value1"을 th:href="value2"의 값으로 변경 HTML을 그대로 볼 때는 href 속성이 사용되고, 뷰 템플릿을 거치면 th:href 의 값이 href 로 대체되면서 동적으로 변경 속성 변경 - th:onclick onclick="location.href='addForm.html'" th:onclick="|location.href='@{/basic/items/add}'|" 리터럴 대체 - |...| 타임리프에서 문자와 표현식 등은 분리되어 있기 때문에 더해서 사용해야 함 리터럴 대체 문법을 사용하면, 더하기 없이 편리하게 사용 가능 반복 출력 - th:each 모델에 ..
@RestController @Controller는 반환 값이 String 이면 뷰 이름으로 인식됨 → 뷰를 찾고 뷰가 랜더링 됨 @RestController는 반환 값으로 뷰를 찾는 것이 아니라, HTTP 메시지 바디에 바로 입력함 해당 컨트롤러에 모두 @ResponseBody가 적용 - Rest API(HTTP API)를 만들 때 사용하는 컨트롤러 @RequestMapping("/xx") /xx URL 호출이 오면 이 메서드가 실행되도록 매핑 대부분의 속성을 배열로 제공하므로 다중 설정 가능 PathVariable(경로 변수) 사용 @GetMapping("/mapping/{userId}") public String mappingPath(@PathVariable("userId") String data)..
Controller HTTP 요청을 받아서 파라미터를 검증하고, 비즈니스 로직을 실행 뷰에 전달할 결과 데이터를 조회해서 모델에 담음 Model 뷰에 출력할 데이터를 담아둠 뷰가 필요한 데이터를 모두 모델에 담아서 전달해주는 덕분에 뷰는 비즈니스 로직이나 데이터 접근을 몰라도 되고, 화면을 렌더링 하는 일에 집중할 수 있음 View 모델에 담겨있는 데이터를 사용해서 화면을 그리는 일에 집중 HTML을 생성하는 부분 스프링 MVC 전체 구조 핸들러 조회: 핸들러 매핑을 통해 요청 URL에 매핑된 핸들러(컨트롤러)를 조회 핸들러 어댑터 조회: 핸들러를 실행할 수 있는 핸들러 어댑터를 조회 핸들러 어댑터 실행: 핸들러 어댑터를 실행 핸들러 실행: 핸들러 어댑터가 실제 핸들러를 실행 ModelAndView 반환..
객체 지향 설계의 5가지 원칙 (SOLID) SRP: 단일 책임 원칙(single responsibility principle) OCP: 개방-폐쇄 원칙 (Open/closed principle) 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 함 LSP: 리스코프 치환 원칙 (Liskov substitution principle) 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위 한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요 ISP: 인터페이스 분리 원칙 (Interface segregation principle) 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 나음 DIP: 의존관계 역전 원칙 (Depe..
MVC, 템플릿 엔진 컨트롤러에서 리턴 값으로 문자를 반환하면 뷰 리졸버(viewResolver)가 화면을 찾아서 처리 스프링 부트 템플릿엔진 기본 viewName 매핑 resources:templates/ +{ViewName}+ .html @ResponseBody 원리 HTTP의 BODY에 문자 내용을 직접 반환 viewResolver 대신에 HttpMessageConverter 가 동작 기본 문자처리: StringHttpMessageConverter 기본 객체처리: MappingJackson2HttpMessageConverter byte 처리 등등 기타 여러 HttpMessageConverter가 기본으로 등록되어 있음 스프링 빈을 등록하는 2가지 방법 컴포넌트 스캔과 자동 의존관계 설정 @Compo..
Java에서의 예외 처리 → try-catch 문 Spring Boot 에서의 에러 처리 @ControllerAdvice 컨트롤러에 대해 전역적으로 ExceptionHandler를 적용해줌 -> 전역적으로 에러를 다루는 클래스로 에러 처리를 위임 @RestControllerAdvice -> @ResponseBody가 붙어있어 응답을 JSON으로 내려줌 하나의 클래스로 모든 컨트롤러에 예외 처리가 가능 직접 정의한 에러 응답을 클라이언트에게 줄 수 있음 별도의 try-catch 문이 없어 코드의 가독성이 높아짐 @RestControllerAdvice를 이용한 Spring 예외 처리 1. 에러 코드 정의 @Getter @RequiredArgsConstructor public interface ErrorCod..
MVC 구조 Request -> Router -> Controller -> Service/Provider -> DAO -> DB DB -> DAO -> Service/Provider -> Controller -> Router -> Response Spring boot Request(시작) / Response(끝) ⇄ Controller(= Router + Controller) ⇄ Service (CUD) / Provider (R) ⇄ DAO (DB) Router 외부에서 요청을 받아 URI와 매핑된 Controller에 전달 Controller Request를 Service/Provider에게 넘겨주고 응답 형식적 Vaildation(값, 길이 등) -> DB를 거치지 않고 요청 데이터의 유효 여부 검증..
