25G.story

API라고 하는 이유는 데이터만 리턴하는 컨트롤러만 만들 것이기 때문입니다. Service에서 받는 매개변수가 int이기때문에 오브젝트 타입인 fromUserId나 toUserId를 좀 더 편하게 받아내고 내 의도대로 insert와 delete를 해주기 위해서 native쿼리를 짜서 설계했습니다 예외 처리하기 똑같은 유저가 다시 구독하기를 똑같은 유저한테 하게 되면 예외가 발생한다. API주소 시큐리티 설정하기

연관관계 먼저 구독하기 API를 구현함에 앞서서 연관관계에 대해서 분석을 해야 한다. 기본적인 공식 제1 정규형인 원자성만 지켜지면 웬만해선 다 해결된다. - 1 : N의 연관관계에서는 폴인키(FK)를 Many가 가진다. - N : N 의 관계가 됐을 때는 테이블을 쪼개서 중간 테이블을 만들어 관리한다. -그리고 이 중간 테이블과의 관계는 중간 테이블이 1, 연관 테이블이 N이 된다. 구독하기는 유저끼리 서로가 해주는 것이기 때문에 N:N의 연관관계가 나온다. 그렇기 때문에 위 공식에 맞게 중간 테이블을 만들어서 관리를 해준다. 모델 만들기 @Table을 사용해서 fromUser와 toUser가 구독을 했을 때 한 번만 db에 등록되도록 Unique제약조건을 걸었다

현제 프로젝트에서 회원 수정을 하는 로직입니다. 22번 줄에 회원을 셀렉트 하기 위해 기본키를 사용하는데 이때 만약에 DB에 없는 데이터를 select를 하게 되면 오류가 나게 됩니다. 이 부분을 잡기 위해서는 orElseThrow()를 사용해야 합니다. 람다식으로 작성했는데 exception을 날릴 때 공통으로 처리하는 @ControllerAdvice에서 관리하는 공통 Exception처리를 사용해서 예외를 날리도록 처리했다.

지금 만들고 있는 web에 공부하면서 알게된 로직들을 포스팅했습니다. build패턴 모델에 Builder어노테이션 dto에 다음과 같은 함수를 만들면 user에 잘 담겨진다. @Service AuthController에서 AuthService클래스 파일을 di(의존성 주입)을 시킨다. 스프링이 IOC컨테이너에 AuthController객체를 생성해서 메모리 로드를 할 때 조건이 생성자 실행이다. 스프링 입장에서 생성자를 실행하려 하는데 생성자 매개변수로 AuthService가 들어가 있으면 AuthService를 주입해 주기 위해 IOC컨테이너를 찾아다닌다 (IOC에 없으면 생성자 실행이 안돼서 오류남). 그래서 @Service를 사용해서 AuthService를 ioc에 등록해주고 의존성 주입을 해주는 ..

공부를 할 때는 실무 스킬보다 원리를 파악하는 것이 중요하다. git == DVCS(분산 버전 관리 시스템) 작업 폴더에서 git init을 통해서 작업 영역을 만들면 그 작업 영역에 대한 변경 감지를 시작한다. 변경 감지를 하다가 변경이 감지가 됐을 때 그 변경을 git add. 를통해서 저장을 하는데 이때 인데스 영역에서 tree형태로 해시 코드를 관리한다. 그리고 그 상태를 영구히 저장을 하고 싶다 즉 버전을 남기고 싶을 때 commit을 통해서 해더 영역에 영구히 저장을 할 수 있게 된다는 것이다. 이렇게만 생각하면 단순히 버전 관리시스템이라고 생각할 수 있는데 git은 버전이 늘어갈수록 add. 를 통한 인덱스 영역에 관리하는 버전이 많아질 수 록 강점이 드러난다. 위 그림과 같이 tree형태로..

1. 구체적인 데이터 요청 시에 쿼리 스트링이나 주소 변수 매핑이 필요하다. 2. 스프링부트에서는 주소 변수 매핑을 주로 사용한다. 훨씬 편리하다. 쿼리스트링은 구체적인 요청을 할 때 "?"를 사용해서 이 "?"를 기준으로 그 뒤에 키와 값의 형태로 데이터를 요청을 하는 것이다. 쿼리스트링방식 위와 같이 구체적인 요청을 쿼리 스트링을 통해서 할 수 있다. 메서드의 파라미터를 전달해주기만 하면 된다. @Pathvariable방식 {type}으로 해놓고 매개변수로 type을 한 후 @Pathvariable로 ioc컨테이너에 등록해 놓으면 스프링에서 자체적으로 파싱 해서 값을 쏙 넣어준다. 스프링에서는 쿼리스트링보단 @Pathvariable을 선호한다.

YML파일 이해하기 음료 공장을 만드는 기술자 1. 두 번째 공장 2. 공장 입구는 서쪽 3. 음료 요청은 전부 한글 문서로 변경해서 받는다. 4. 음료는 전부 콜라로 만들어서 출시된다. 5. 음료 총고는 컨테이너 박스를 사용한다. 6. 음료는 요청에 따라 페트병, 캔, 병으로 출시된다. 7. 공장이 재가동 될때 기존에 만들어졌던 음료는 버리지 않는다. 8. 음료 요청 시 A4용지 2장 이상의 문서는 받지 않는다. 9. 음료 요청은 아무나 할 수 없다. 암호를 아는 사람만 요청한다. 이런 문서와 규칙에따라서 기술자는 음료공장을 만들듯이 스프링 프레임워크에서 YML파일이란? 스프링 프레임워크로 공장을 만들 것인데 이 공장을 만들기 위한 문서다. 스프링 프레임워크 서버가 만들어질 때 스프링에서 이 YML파일..

어댑터 패턴 일상생활에서의 어댑터는 일반적으로 걸러내는 역할을 한다. 인터페이스가 너무 많은 행위의 제약을 가지고 있으면 경우에 따라서 걸러내기 위해서 추상 클래스로 걸러낼 메서드를 오버라이드 해서 해당 인터페이스를 상속받으면 경우에따라서 행위의 제약을 벗어 날 수 있다. 하지만! 자바는 다중상속을 재한 하기 때문에 어댑터 패턴의 단점은 분명하다. 그래서 나온것이 interface내부에서 default라는 문법이 생겨 난 것이다. default는 인터페이스도 몸체가 있는 메서드를 만들 수 있다. 왜 이 문법이 생겼냐?! (다중 상속이 안 되는 것이 많기 때문이다.) 그래서 최근의 자바버전에선 어댑터 패턴 대신에 default를 사용하는 것이 좋다

일대일로 소켓통신을 하는 것은 한 방향으로만 이루어진다. 쓰는 쪽(클라이언트)과 읽는 쪽(서버). 일대일 방식의 소켓통신을 그림으로 표현해 봤는데 여기서 먼저 개선해야 할 부분은 클라이언트가 메시지 한 개만 보내면 프로그램이 종료되는 것이다. 이럴 때 종료되지 않고 "반복"되게 하기 위해서 while을 사용해서 메시지를 보내더라도 프로그램이 계속 돌도록 해본다. 자 그럼 이제 하나의 문제점을 개선했는데 개선을 해놓고 보니 클라이언트만 일방적으로 메시지를 보내고 서버는 그 메시지를 읽기만 한다. 완전한 단방향 통신이다. 이를 어떻게 개선해야 할까? 이문제를 개선하기 위해서는 먼저 스레드에 대해서 생각을 해 봐야 한다. 지금 현제 위 프로그램에서 java는 main스레드 하나가 동기적으로 열심히 쓰고 읽고를..

소켓통신을 일대일 방식으로 하려면 두 개의 소캣이 필요하다 서버 소켓과 클라이언트소켓 그럼 이 두 개의 소켓을 ByteStream으로 연결하는데 ip주소로 서로 통신할 수 있도록 할 것입니다. 포트를 양 끝단에 달고 하는 통신(소켓통신) 다음과 같은 방식으로 통신이 이루어집니다. 위 그림에는 빠져있지만 클라이언트 소켓은 메시지를 쓰는 쪽이기 때문에 키보드와 연결하는 스트림이 하나 더 있어야 합니다.(클라이언트 파일 소스코드 참고) 서버 소켓 파일 import java.io.BufferedReader; import java.io.InputStreamReader; import java.net.ServerSocket; import java.net.Socket; public class ServerFile { /..