기존의 SQL, JDBC API를 사용하면서 애플리케이션의 비즈니스 로직보다 SQL과 JDBC API를 작성하는 데 더 많은 시간을 소비했었다.이게 조금 나아지면서 JdbcTemplate같은 SQL매퍼를 사용해서 코드 양을 줄였다. 그렇지만 여전히 CRUD는 작성해야 한다.이건 너무 비생산적인 반복이라고 한다. 영한님이 생각한 것은 객체지향의 장점을 살린 객체모델링을 적용하는 것이었다.하지만 객체 모델링은 세밀해질 수록 저장과 조회가 어려웠다. 결국 데이터 중심 모델로 변해간다는 결과가 나왔다고 한다. 그래서 이런 객체와 관계형 데이터베이스(RDB) 간의 차이를 중간에서 해결하기 위해 ORM(object relational mapping)이 찾았다고 한다. 나도 이런 문제해결적 공부를 할 수 있을까 시작..

인턴생활을 시작하면서 매일 회사, 집, 회사, 집만 하면서 너무 아무것도 안하고 시간만 지나가는 느낌을 받았다.이런저런 일들이 너무 많았고, 나의 개발적 발전이 완전히 정체되었다는걸 오늘 아침 깨달았다...그래서!! 오늘부터 다시 개발공부를 시작한다. 어제 새로 들어온 신입생들 백엔드 교육을 해주면서 나도 저럴때가 있었지ㅎㅎ 하면서 뭔가 다시 자극을 받은 것 같다.이제 진짜 내 자신을 위해서 공부하고, 개발하고, 성장해야겠다. 그래서 일단 아직까지도 시작을 못한 주먹구구식 공부를 해 온 JPA를 공부하려고 한다.

command + shift + R -> 디렉토리 하위의 동일한 문자를 한번에 모두 바꿀 수 있다. R = replace의 약자 command + R -> 소스코드에서 찾은 동일한 문자를 한번에 모두 바꿀 수 있다. command + option + v -> 변수선언 시 코드를 자동완성해준다. shift+F6+fn -> 동시에 변수 이름 바꾸기 command + o -> 클래스 찾아서 이동 command + option + c -> 상수로 만들기 command + shift + 8 - 다중커서 모드 키기 -> shift+방향키로 줄별 커서 생성해서 사용 esc로 종료 command + option + shift + U -> class 다이어그램 보기 command + option + c -> string..

서블릿 자체 예외 처리 @Slf4j @Controller public class ServletExController { @GetMapping("/error-ex") public void errorEx(){ throw new RuntimeException("예외 발생!"); } @GetMapping("/error-404") public void error404(HttpServletResponse response) throws IOException { response.sendError(404,"404 오류"); } @GetMapping("/error-500") public void error500(HttpServletResponse response) throws IOException { response.se..

package hello.login.web.interceptor; import lombok.extern.slf4j.Slf4j; import org.springframework.web.method.HandlerMethod; import org.springframework.web.servlet.HandlerInterceptor; import org.springframework.web.servlet.ModelAndView; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.util.UUID; @Slf4j public class LogInterceptor implements ..

스프링 인터셉터는 서블릿 필터와 마찬가지로 웹과 관련된 공통 관심 사항을 효과적으로 해결할 수 있는 기술이다. 공통 관심 사항이란 로그인을 해야 서비스를 이용할 수 있는 대부분의 웹 서비스에서 로그인을 하지 않은 사용자의 접근을 제한하기위해 모든 컨트롤러 로직에 로그인 여부를 확인하는 코드를 작성하는 비효율적 행위를 막아햐한다. 이렇게 많은 로직에서 공통으로 관심이 있는 부분을 공통 관심사라 한다. 스프링 인터셉터의 흐름 HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터 -> 컨트롤러 스프링 인터셉터는 스프링 MVC가 제공하는 기능이다. 때문에 디스패처 서블릿 이후에 등장하게 된다. 스프링 인터셉터에 URL 패턴을 매우 정밀하게 적용할 수 있다. 스프링 인터셉터 제한 HTTP 요청 ..

오류 코드를 만들 때 다음과 같이 자세히 만들 수도 있고, required.item.itemName : 상품 이름은 필수입니다. range.item.price : 상품의 가격 범위 오류 입니다. 또는 다음과 같이 단순하게 만들 수도 있다. required : 필수 값 입니다. range : 범위 오류 입니다. 단순하게 만들면 범용성이 좋아서 여러곳에서 사용할 수 있지만, 메시지를 세밀하게 작성하기 어렵다. 반대로 너무 자세하게 만들면 범용성이 떨어진다. 가장 좋은 방법은 범용성으로 사용하다가, 세밀하게 작성해야 하는 경우에는 세밀한 내용이 적용되도록 메시지에 단계를 두는 방법이다. 예를 들어서 required 라고 오류 코드를 사용한다고 가정해보자. 다음과 같이 required 라는 메시지만 있으면 이 ..

FieldError 생성자 public FieldError(String objectName, String field, String defaultMessage); public FieldError(String objectName, String field, @Nullable Object rejectedValue, boolean bindingFailure, @Nullable String[] codes, @Nullable Object[] arguments, @Nullable String defaultMessage) objectName : 오류 발생 객체 이름 field : 오류 필드 rejectedValue : 사용자가 입력한 값 bindingFailure : 타입 오류 같은 바인딩 실패 or 검증 실패 구분 값..