
📌 해결해야하는 문제 A 필드 값에 B 라는 문자열이 있을 때 C 필드는 비어있으면 안된다.(@NotBlank) 이 상황에 맞게 validation을 체크할 수 있도록 custom validation annotation을 만들었다. 📌 STEP 1. Validation Annotation 만들기 annotation에서 필요한 값들 1. field : 값을 체크해야하는 필드 (A) 2. fieldContains : field의 값이 포함해야하는 문자열 (B) 3. targetField : field의 값에 fieldConatins 문자열이 있을 때 비어있으면 안되는 필드 (C) → field 값에 fieldContains 문자열이 있으면 targetField @NotBlank 제약조건 체크 📌 STEP 2..
HTTP 요청 DispatcherServlet HandlerMapping이 해당 요청을 처리할 핸들러를 찾는다. RequestMappingHandlerMapping : 애노테이션 기반의 컨트롤러인 @RequestMapping에서 사용한다. BeanNameUrlHandlerMapping : 스프링 빈 이름으로 핸들러를 찾는다. 핸들러를 호출할 HandlerAdpater를 찾는다. RequestMappingHandlerAdapter : 애노테이션 기반의 컨트롤러인 @RequestMapping에서 사용한다. SimpleControllerHanderAdpater : Controller 인터페이스 구현한 핸들러 처리 HttpRequestHandlerAdapter : HttpRequestHandler 인터페이스를 ..
@SessionAttributes와 SessionStatus 서블릿은 기본적으로 상태를 유지하지 않는다. 도메인 오브젝트로 사용자 정보를 수정하기 사용자 정보는 사용자가 수정할 수 없는 데이터와 수정할 수 있는 데이터가 있다. 수정하면 안되는 정보는 form에 보여주지 않는 것이 좋다. form submit으로 수정할 때 고객이 수정하지 못하는 데이터는 null, 0으로 전달될 가능성이 있다. 히든 필드 사용해서 해결 사용자가 수정하면 안되는 정보는 hidden 필드에 넣는다. 데이터 보안에 문제를 일으킨다. (html에서 조작할 수 있다.) 새로운 필드가 추가될 때 히든 필드도 추가해야한다. 실수할 가능성이 높아진다. DB 재조회하기 수정된 정보를 받아 도메인 객체에 넣어줄 때 DB에서 데이터를 다시 ..
@MVC 애노테이션을 중심으로 한 새로운 MVC의 확장 기능 @RequestMapping 핸들러 매핑 DefaultAnnotationHandlerMapping 빈을 등록해야한다. 매핑정보로 @RequestMapping 애노테이션을 활용한다. 타입 레벨에 @RequestMapping을 이용해서 타입 내의 매핑 메소드의 공통 조건(url)을 지정할 수 있다. @Controller를 사용하면 클래스 레벨에서는 @RequestMapping을 생략할 수 있다. @RequestMapping 정보는 상속되지만 서브 클래스에서 재정의 하면 슈퍼 클래스의 정보는 무시된다. 속성 value() URL 패턴 지정, 와일드 카드를 사용할 수 있다. {}로 PATH VARIABLE 지정할 수 있다. method() 요청 메소드..
기타 리졸버 핸들러 예외 리졸버 HandlerExceptionResolver : 컨트롤러 작업 중 발생한 예외를 어떻게 처리할지를 결정하는 전략. 예외 발생 > 핸들러 예외 리졸버 확인 > 있으면 핸들러 예외 리졸버가 처리, 아니면 서블릿 컨테이너가 처리 AnnotationMethodHandlerExcpetionResolver : @ExceptionHandler 애노테이션이 붙은 메소드가 예외처리한다. 특정 컨트롤러 작업 중 발생하는 예외를 처리하는 핸들러를 만들 때 유용하다. ResponseStatusExceptionResolver : 예외를 특정 HTTP 응답 상태로 전환해준다. DefaultHandlerExceptionResolver : 스프링에서 내부적으로 발생하는 주요 예외를 처리. Simple..

프론트 컨트롤러 패턴 (스프링 MVC의 DispatcherServlet) - 기존에는 모든 컨트롤러에 공통로직이 중복되었다. - 요청을 받으면 공통 로직을 프론트 컨트롤러가 처리한 뒤 요청에 맞는 컨트롤러를 호출한다. - 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 된다. 스프링 MVC 1. 프론트 컨트롤러 도입 - FrontController에서 Request의 URL에 따라 Request를 처리할 컨트롤러를 찾는다. (controllerMap) - 해당 컨트롤러를 호출한다. 2. 중복되는 뷰의 로직 분리하기 - View 객체를 만들어서 뷰를 렌더링하는 함수 생성 - 컨트롤러에서는 뷰 객체를 생성해서 반환하고 프론트 컨트롤러에서 뷰 객체를 받아 render함수를 호출하면 뷰를 렌..
- Total
- Today
- Yesterday
- spring boot
- 스프링 부트 테스트
- DataAnnotation
- 스프링
- Effective Java
- Java
- JavaScript
- @Modifying
- orphanRemoval
- 빌더 패턴
- 준영속
- 고아 객체
- 스프링MVC
- default interface
- uploadfive
- c#
- MSSQL
- ASP.NET
- C# 문법
- 영속성
- SpringBoot
- Nullable
- 다이내믹 프록시
- JpaRepository
- 자바의 정석
- 토비의 스프링
- Spring
- JPA
- jQuery
- OWIN
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |