개발자로 후회없는 삶 살기

서론※ 과거에 기록한 내용에서 중요한 부분만 발췌하여 모두가 이해하기 쉽게 다시 서술한다. 본론- 자바 예외 원칙1) 거의 대부분 런타임 예외를 사용2) 체크 예외는 잘 안 쓰고, 비즈니스 로직상 너무 중요해서 의도적으로 던질 때만 사용 -> 예시해당 예외를 잡아서 반드시 처리해야 하는 문제일 때만 체크를 사용하고 나머지는 다 언체크 사용 🚨 체크 예외의 문제점무조건 잡거나, 잡지 못하면 throw를 선언해 던져야만 한다. DB나 네트워크 오류는 어플리케이션 로직에서 처리할 방법이 없다. 그래서 이들이 체크 예외라면 모두 밖으로 throws를 선언하고 던져야한다. 컨트롤러도 던지면 was에서 controlladvice에서 공통으로 처리하는데 이러한 오류는 500 에러로 해결이 불가능한 공통 예외는 고객..

서론※ 과거에 기록한 내용에서 중요한 부분만 발췌하여 모두가 이해하기 쉽게 다시 서술한다. 본론- DB 연결 구조와 세션10개의 커낵션 = 10개의 세션DB에 접근하면 커낵션이 생기고 세션이 열리며, 하나의 세션에서 트랜잭션을 시작해서 SQL을 수행한다. -> 정리커낵션을 연결하면 db 내부에 세션이 생기고 세션을 통해 트랜잭션을 시작하고 sql을 실행한다. 트랜잭션을 시작할 때 락을 획득하고 끝나면 락을 반납한다. - 실제 로직에 트랜잭션 적용계좌 이체가 안 되는 비즈니스 상황에 트랜잭션을 적용해보자 입금을 성공하는데 출금에서 실패하는 경우이다. when에서 예외가 발생해서 출금은 성공하는데 입금에서 실패한다. 테스트에서 DB를 사용하면 pk 자동 증가 때문에 막힌다. 테스트에서 트랜잭션을 사용하면 테..

서론※ 과거에 기록한 내용에서 중요한 부분만 발췌하여 모두가 이해하기 쉽게 다시 서술한다. 본론→ html 폼 전송 방식1) x-wwwx-www 방식은 name=value 형식으로 문자를 전달한다. 하지만, x-www는 문자와 파일을 함께 전달할 수 없다. 파일은 InputStream에 저장되는 바이어리 데이터라서 문자에 담을 수 없다. 실무에서는 한 번에 문자와 파일을 입력 받는 경우가 많다.  2) multipart/form-datamultipart 방식은 boundary를 경계로 여러 파트로 나눠서 문자와 파일을 함께 전달할 수 있다. content-type은 image/png로 엔터하고 파일 바이너리 데이터가 들어간다. → 실행개발자 도구로 보면 content type과 경계가 보인다. 바운더리를..

서론※ 과거에 기록한 내용에서 중요한 부분만 발췌하여 모두가 이해하기 쉽게 다시 서술한다. 본론- 예외 처리와 오류 페이지스프링에서 예외가 발생했을 때 어떻게 처리하는지 알아보자 - 서블릿 예외처리1) 예외가 발생하여 was에게 예외가 날라감 2) resp.sendError 호출로 예외가 발생한 것처럼 가장서블릿은 2가지 방법으로 예외를 지원한다. 1. exception자바에서 메인 메서드를 호출하면 main이라는 스레드가 생성된다. 프로그램이 진행되며 예외가 발생하면 이를 잡으면 문제가 없지만, 못 잡으면 호출한 상위 스택까지 예외가 전달되고 메인 메서드 밖까지 예외가 전달되면 스레드가 종료된다. 웹 어플은 하나의 스레드가 있는게 아니라, 사용자 요청별로 별도의 스레드가 할당되고 그 스레드가 서블릿, ..

서론※ 과거에 기록한 내용에서 중요한 부분만 발췌하여 모두가 이해하기 쉽게 다시 서술한다. 본론- 서블릿 필터로그인한 사용자만 상품 목록을 볼 수 있도록 해야하는데, 현재는 URL을 직접 입력하면 로그인 안 한 사용자도 접근 가능하다. 이를 해결하는 방법으로, 모든 컨트롤러에 세션 검증 코드를 넣을 수 있다. 근데 이는 같은 기능을 반복하여 중복이 발생하고, 번거롭다. 지금, 사용자가 인증이 된 사용자인지 인증에 대해 공통으로 관심을 가지고 있다. 공통 관심사는 AOP로도 해결할 수 있지만 웹과 관련된 것은 서블릿 필터와 스프링 인터셉터를 사용하여 Http 관련 공통 관심사를 처리해준다. 이들은 특정 URL이 오는 건 다 막는다는 등 웹 관련 부가 사항을 제공하여 로그인 여부 체크하는 로직을 한 방에 해..

서론※ 과거에 기록한 내용에서 중요한 부분만 발췌하여 모두가 이해하기 쉽게 다시 서술한다. 본론- 검증 요구사항타입 검증 : 가격, 수량엔 숫자만 가능 필드 검증 : null 불가, 가격에 범위 검증, 수량 검증지금까지 만든 프로그램은 상품명을 입력 안해도 되고, 가격, 수량에 문자를 적으도 된다. 웹 서비스는 이러한 것을 모두 검증으로 막아야 한다. 검증 실패시 중요한 것은 고객의 편의성이다. 폼에 고객이 넣은 데이터 그대로 다시 보여줘야 한다. 기존 정보와 error 정보를 담아서 폼에 넣어야 한다. - 검증 하기컨트롤러에 검증 로직을 작성한다. 먼저 오류가 뜨면, 어떤 오류가 떴나 담는 객체가 필요하다. 검증 오류를 보관하는 Map을 만든다. 필드 별로 실패 정보를 담는다. -> 검증에 실패오류가 ..

서론※ 과거에 기록한 내용에서 중요한 부분만 발췌하여 모두가 이해하기 쉽게 다시 서술한다. 본론- Http 요청 메세지(단순 텍스트)서블릿에서는 메세지 바디 데이터를 읽기 위해선 InputStream으로 바디 데이터를 스트림 데이터로 저장하고 인코딩하여 문자로 변환해야 한다. 스프링에서는 Http 바디에 있는 것을 원하는 포멧으로 바꿔주는 HttpMessageConverter가 동작한다. HttpEntity는 바디 정보를 편리하게 조회할 수 있는 객체이다. -> 개선http entity를 쓰는 것도 개선하여, requestbody가 제공된다. 이는 바디에서 데이터를 읽어서 문자로 바꿔버린다. HttpMessageConverter는 바디 데이터를 스트림으로 바이트 데이터를 받고 string으로 utf8로 ..

서론※ 과거에 기록한 내용에서 중요한 부분만 발췌하여 모두가 이해하기 쉽게 다시 서술한다. 본론- 스프링 MVC 전체 구조Dispatcher Servlet : 프론트 컨트롤러Handler Mapping : 핸들러를 보관하는 맵 - 디스패쳐 서블릿 구조 살펴보기스프링도 프론트 컨트롤러 패턴을 사용한다. HttpServlet을 상속 받고, urlPattens를 "/'로 모든 요청을 받는다. -> 요청 흐름디스패쳐 핸들러의 doDispatch 메서드에서 핸들러 매핑을 찾고 핸들러 매핑을 인자로 핸들러 어댑터를 찾는다. get 메서드 내부를 보면 for문으로 support 메서드로 해당 핸들러를 처리할 수있는 어댑터를 찾는다. 어댑터는 support 메서드를 가지고 handle로 컨트롤러를 호출한다. -> 스프..