앞에서 해온 방식인데 DriverManager를 통해 getConnection()을 했었다. 그래서 뭔가를 할 때마다 연결하고 닫고 연결하고 닫고.. 드라이버랑 실제 DB랑 연결하는 방식은 http에서 했던 것처럼 TCP/IP 통신이라 3 way handshake같은것들도 다 한 뒤에 연결되면 id, pw 및 부가 정보를 전달하면 db에서 확인하고 검증되었으면 내부에 세션을 생성해서 완료했다는 응답 메시지를 클라이언트한테 보냈다. 이 커넥션 시간도 DB마다 다르다. 이게 원리고 정석이지만, 너무 많은 시간 및 자원 낭비가 있었다. 그래서 커넥션 풀이라고 미리 여러개 연결시켜놓은 뒤 닫지 않고 계속 써먹는거다. 기본적으로 10개 정도 사용한다고 하고, 서버 사용자 상황에 따라 늘리거나 줄인다. 거기다 갯수..

섹션0의 소개란. 밑부터 섹션1 시작 h2를 스프링의 버전에 맞춰서 설치하고 강의대로 사전세팅해서 정상작동하는걸 확인했다. 들어가기 전에 역사를 좀 알아야 왜 이렇게 개판이고 저건 또 뭔지 이해할 수 있다. DB란 개념은 원래 있었다. 중요한 정보를 보관하는 곳이다. 문제는 각 회사마다 연결해야 하는 방법이 달랐다. 그래서 만약 다른 DB를 쓰게 된다면 코드를 다시 작성해야 했었다. 그래서 나온게 드라이버를 사용하기로 했다. 놀랍게도 각 회사에서 자기가 드라이버용 자바 코드를 짜서 주었다. 그걸 가져다가 사용하기만 하면 되었다. ㅇㅇ 됨. 참고사항은 JDBC의 등장으로 많은 것이 편리해졌지만, 각각의 데이터베이스마다 SQL, 데이터타입 등의 일부 사용법이 다르다. ANSI SQL이라는 표준이 있어서 어느..

지금까지 보내던 HTTP의 enctype 방식은 x-www-form-urlencoded나 application/json 형식이었다. 즉 기껏해야 string이고 구분자도 그냥 편하게 되어있어서 잘 했다. 그런데 바이너리인 파일은 어떻게 보낼 것인가? 만약 이름, 나이, 이미지파일 같은 형식으로 string과 binary파일을 같이 보내야 한다면?? 이런것 때문에 enctype="multipart/form-data" 방식이 나왔다. part라는게 서버 내에서도 중요한가 보다. 다른 string과 함께 이미지 파일 아무거나 binary 형태로 해서 multipart/form-data로 보낸걸 보면 실제 이론에서 배운것처럼 구분자가 있고 각자의 헤더와 내용이 들어있음을 알 수 있다. 컨트롤러에서 받는 requ..

http의 요청으로 오는 모든 데이터들은 string으로 와서 일일히 변환해야 하는데 컨트롤러에서 그냥 다른 타입으로 받을 수 있었던 이유는 자체 내부에서 컨버터가 있었기 때문. 이를 이해하기 위해 직접 구현해본다. 잘 된다. 이번엔 컨버터를 직접 만들어보자. 잘 된다. 또 컨버터도 이미 여러 종류가 있고 생각할만한 것은 이미 스프링에서 미리 다 만들어놓았다고 한다. 근데 직접 만든걸 자세히 보면 스프링이 관여한 곳이 없다. 직접 컨버터 클래스 만들고 했을 뿐.. 그래서 이렇게 직접 만들어 놓은 컨버터를 컨버전 서비스(ConversionService)라는 곳에 등록해놓고 꺼내쓰기만 하면 된다. 진짜 등록하고 클래스 유형만 주면 지가 알아서 찾아서 정의한거 찾아서 쓴다. 그러니까 사용하는 사람은 (등록은 ..

아까는 웹에 대한 거였지만 이젠 API서버에서 예외 처리에 대해 알아본다. 풀어놨던 설정을 다시 활성화 한다. 시험용으로 간단하게 만든다. postman으로 시험해본다. 에러가 떴을 때 지난 설정이 그대로 있으므로, 에러 형태에 따라 설정한 곳의 url를 반환해서 결국은 웹 뷰 html를 반환할 것이다. 같은 에러 반환용 url이지만, 클라이언트가 헤더에서 건네는 받을 수 있는 요청을 더 구체적으로 정해줘서 해준다. json으로 반환할 거니 Map

서블릿은 그냥 자바 쌩 오류인 Exception과 response.sendError 2가지 방식으로 예외를 처리한다. sendError로 하면 status code도 전달 가능. 에러가 떴을 때 스프링을 통해 에러 페이지를 띄워주는 과정인데, 컨트롤러에서 에러가 뜨면 타고타고 올라가서 WAS가 처리한다. 에러일 경우 WebServerCustomizer에서 new ErrorPage에 등록되어 있는 에러 목록에 들어가서 해당 url을 다시 실행시킨다. 그래서 에러용 url 화면을 띄울 html와 controller를 만들어야 한다. 이렇게 WAS만을 이용해서 처리하는 문제점은, 필터, 서블릿, 인터셉터 들이 다시 한 번 사용된다는 것이다. 지금은 아무것도 없어서 괜찮지만 만약 인터셉터에 로그인 로직을 넣는다..

필터 전에 공통 관심사라는 개념을 이해해야 하는데, 컨트롤러를 만들고 요청을 처리하지만 로그인이 되어있다고 가정하고 요청을 처리하는 서비스가 많을 것이다. 이런 것들은 전에 했던 것처럼 일일히 다 코드로 넣기는 힘드니 컨트롤러 서비스 처리 함수로 가기 전에 어딘가를 공통적으로 들른 후 가게 하는게 좋다. 예전에 수문장이라고 배운게 있지만 HTTP 요청은 이 요청용 필터로 쓰라고 만든 게 있다. 이걸 써서 로그인 했으면 로그인 로직 처리해서 넘기고 아니면 거절하고 하는 걸 사용할거다. 진짜 filter를 하는군 doFilter라서 이것만 보면 된다. 그냥 ServletRequest는 기능이 별로 없고 어차피 거의 Http쓸 거라서 그냥 저렇게 캐스팅으로 바꿔도 된다. chain.doFilter를 통해 들어..

도메인이 제일 중요하다. 화면, 인프라, UI등을 모두 제외한 시스템이 구현해야 하는 핵심 비즈니스 업무 영역이다. 그래서 웹이든 뭐든 다 여기를 기반으로 의존해야 하고, 도메인은 어딘가에 의존하지 않고 마음대로 할 수 있어야 잘 짠거임. 멤버 로그인을 구현한건데, 앞에서 배웠던 것들을 하나로 합친 김에 무슨일이 일어난건지 정리해보자. 일단 핵심 기능인 멤버 도메인을 정의하고 그 멤버들을 저장하는 레퍼지토리를 만든다. 이때 멤버에도 제약을 둘 수 있고, 원래 이 레퍼지토리를 데이터베이스 같은 곳에 담겠지만 일단 메모리에 저장한다. 멤버를 저장하고 멤버를 불러오는 코드는 레퍼지토리 클래스가 관리한다. 로그인 폼을 만드는데, 로그인 폼은 로그인 용 서비스 클래스를 만들어 폼과 HTTP 요청을 주고받는데 멤버..

앞에서 했었지만 사실 저런 문제들은 이미 수 많은 개발자들이 겪은 문제라서, 더 쉽게 할 순 없을지 고민 끝에 스프링에서 Bean Validation으로써 간단하게 할 수 있도록 지원한다. public class Item { private Long id; @NotBlank private String itemName; @NotNull @Range(min = 1000, max = 1000000) private Integer price; @NotNull @Max(9999) private Integer quantity; //... } (@NotNull 같은 경우는 갓갓 kotlin에서 기본 지원 타입이다.) 거기다 저렇게 타입 제한 등이 있으면 db에서도 연동해서 쓰기 훨씬 쉽다. 구현체는 validation에..

범위나 타입을 제한하고 클라이언트가 제대로 입력했는지 서버에서도 검증해야 한다. 클라이언트에게도 뭐가 잘못되었는지 알려줘야 납득하고 다시 잘 사용한다. 취약할 수 밖에 없는 이유는 클라이언트에서 자바스크립트로 실행하는데 누구나 할 수 있기 때문. 서버에서만 검증하려면 실시간 검증하는데 힘들 수 있음. 사용자가 적어 올리고 서버에서 검증했는데 성공했을 경우만을 가정해서 코드를 짰다. 잘 성공했으면 불변성 지키기 위해 GET을 날리는 주소인 상품 주소로 리다이렉트 했다. 실패했을 경우, 성공했을 때 처럼 상품 상세로 리다이렉트 하지 말고 해당 추가 폼을 다시 보여주되 실패하도록 입력한 그 값까지 모델에서 저장하여 다시 표시해줘야 한다. 이게 차이점임. 분명 저장 누르면 다시 등록 화면을 보여주는데 값이 그대..