개발일지

socket.io는 별도로 구현하기 때문에 이것과 상관없이 spring은 계획한대로 진행하기로 했다. API 명세 중 우선 방 만들기와 방 참여하기 부분을 구현했다. 로그인이 없이 게임을 참여할 때만 유저를 임시로 만들기로 했기 때문에 이 부분을 어떻게 처리해야 할지 고민이 많았다. 우선은 유저의 nickName을 임의로 주기로 했는데, 로직을 어떻게할지 고민이 많았다. 처음 생각했던 것은 별도의 엔티티를 생성해서 거기서 가져와 쓰는 것이었는데 이렇게 하면 유저가 추가될 때마다 DB가 조회되고, 유저샘플로 저장할 데이터가 많은 것도 아니라 그냥 방을 생성할 때 배열을 만들고 거기서 닉네임을 랜덤으로 꺼내오는 메소드를 만들었다. private String getNickName() { // User에 nic..

스프링 시큐리티는 지난번에 사용한 코드를 거의 그대로 가져와서 금방끝났다. 프론트에서 로그인하시는 분이 지난주에는 노드랑 하셔서 방식이 조금 달랐던 것 같은데, 다행히 다른 프론트 분이 도와주셔서 크게 어려움없이 금방 끝낼 수 있었다. #주문하기 주문하기 부분을 하고 있어서 구현을 했는데, 아직 장바구니 부분이 완료되지 않아서 TestData를 넣고 했다. 이 부분을 하다보니 생성자 메소드를 새로 만들어야 했다. 그리고 ProductInCart를 주문하기로 넘기면서 기존에 있던 Cart와의 연결관계를 끊는 메소드도 추가하였다. public class ProductInCart { ... //연관관계 편의 메소드 public void setCart(Cart cart) { this.cart = cart; ca..

오늘부터 새로운 프로젝트를 시작한다. 처음에 cgv 예매를 하려고 했는데 엔티티를 설계하는데 복잡해져서 주제를 바꾸기로 했다. 몇 개가 후보로 나와서 사다리를 돌렸고, 마켓컬리를 하기로 했다. 메인페이지와 상세페이지, 장바구니 페이지를 만들고 상품을 장바구니에 담고 주문하기 버튼을 누르면 주문하기 테이블에 담는 것 까지 하기로 했다. 추가로 가능하다면 포토리뷰를 작성하는 것을 하기로 했다. 먼저 설계한 엔티티 구조는 다음과 같다. 처음에 ProductInCart와 ProductInOrder을 따로 만들었는데 내용이 거의 똑같아서 고민이 있었다. 저녁에 ERD 세션이 있었는데, 질문에서 좋은 팁을 얻을 수 있었다. ProductInCart에 state라는 Column을 추가해서 장바구니에 담긴 상태에서는 ..

현재 로그인은 기본적으로 controller에 구현되어 있고(로직들이 controller에 너무 많이 들어가 있는 것 같아서 서비스에서 구현되도록 리팩토링했다.), 아마 authenticationManager가 인증하면서 코드에는 보이지 않지만 AuthenticationProvider ~ DB에서 User를 찾아서 UserDetails에 담아 리턴하는 것까지 이루어지는 것 같다. 여기서도 보면 UsernamePasswordAuthenticationFilter를 통해 Authentication Manager로 연결되고 이후 로직들이 처리되는 것을 볼 수 있다. (참고자료: https://webfirewood.tistory.com/115) formLogin을 Disable한 상태고 별도로 Filter를 커스..

오늘부터 프론트와 새로운 미니프로젝트에 들어간다. 계속 스프링 + html 위주로 구현을 해와서 어떻게 프론트와 붙는 건지 아직 잘 이해가 되지 않는다. 회원가입을 어떻게 구현할지 고민이 많았는데, security에 자신이 없어서 기본 세션만 사용을 하고 다른 기능에 좀 더 집중하기로 했다. 우선 회원가입쪽 기능 구현은 완료하고 내일 프론트와 테스트로 붙여보기로 했다. signup은 json으로 받아도 되는 것 같아서 그렇게 했고, 로그인은 form으로만 가능한 것 같다고 다른 분들이 알려주셔서 우선 이렇게 해보기로 했다. signup을 처음에 form으로 받을 때 계속 에러가 났는데, SignupDto에 @Setter를 붙여서 해결했다. 오랜만에 git을 사용해서 깃도 계속 햇갈리는 것 같다. 테이블 ..

오늘은 에러코드를 구현하였다. Spring security쪽 에러는 처리하지 못하고 그외 다른 exception으로 처리한 부분을 모두 ErrorCode로 정리해주었다. #ErrorCode 다음과 같이 각 에러마다 HttpStatus값을 지정하고 에러코드와 메세지를 입력하였다. @Getter public enum ErrorCode { // 400 Bad Request INVALID_MIN_ORDER_PRICE(HttpStatus.BAD_REQUEST, "400_1", "1,000원 ~ 100,000원 사이를 입력해주세요."), TYPE_ERROR_MIN_ORDER_PRICE(HttpStatus.BAD_REQUEST, "400_2", "100원 단위로 입력해주세요."), INVALID_DELIVERY_FE..

어제 구현한 RestaurantMvcTest에 이어 FoodMvcTest와 OrderMvcTest를 만들었다. RestaurantMvcTest에 조금 변형만 하면 되는 거라서 금방 될 줄 알았는데 에러를 해결하는데 생각보더 훨씬 시간이 걸렸다. FoodMvcTest를 작성할 때 음식 등록 api에서 400에러가 발생하였다. 권한 설정으로 발생하는 403 에러가 아니라서 처음에는 서비스 로직을 의심했다. 혹시 리팩토링을 하면서 문제가 생겼는지 확인했는데, arc에서 잘 돌아가는 것을 확인했다. 그래서 restaurantId가 pathvariable로 들어가는데 restaurant를 생성하지 않아서 발생한 에러라고 생각했다. 다른 test code들을 확인하면서 음식점을 등록하는 테스트를 먼저 만들어주고, ..

코드잇에서 cs 듣던 부분을 모두 들었다. 강의가 세세하지는 않지만 큰 흐름을 잡기에 좋은 것 같다. 다른 강의들도 조금씩 들어야겠다. JAVA랑 Spring 공부하려고 산 책을 스캔했다. 세세하게는 못봐도 항해하면서 1회독 하는걸 목표로 해야겠다. Service부분을 추가적으로 리팩토링했다. 처음에는 혼자 리팩토링하는게 어려웠지만 매개변수와 return값만 잘 지정하고 나면 크게 어렵지 않았다. security 권한 부여는 @Secured를 사용했다. 그런데 프론트를 구현해놓지 않아서 ARC로는 테스트가 한계가 있었다. 기존에 테스트 코드도 기능들이 추가되면서 수정이 필요한 상황이었다. 처음에는 기존에 있는 코드에서 수정을 하려고 했는데, security 부분이 들어가서 쉽지 않았다. controlle..

예측이 가능한 에러를 exception처리를 하고 나서 HTTP status와 errorMessage를 보내줄 수 있다. 예를 들어, 클라이언트에서 입력값과 관련된 에러는 500 Internel Server Error가 아니라 400 Bad Request + 에러메세지를 보내서 어떤 부분에서 에러가 난 것인지 알려줄 수 있다. 프론트에서는 이 메세지를 활용해 팝업 등으로 보여줄 수 있다. 스프링에서 제공하는 ResponseEntity를 사용하면 HTTP status Code, HTTP headers, HTTP body를 선언할 수 있다. 그리고 이 클래스를 이용하여 원하는 내용을 클라이언트로 보낼 수 있다. package com.sparta.week03project.exception; import lom..

#DI 강한 결합이란? 다음과 같이 각각 새로운(new) 생성자를 만들어 구현하는 것. 문제점 : 일부 변경시 모든 코드를 다 수정해주어야 함 → 느슨한 결합을 지향 느슨한 결합 새로운 생성자를 만드는 것이 아니라 이미 생성된 객체를 가져다 씀! Repository에 객체 repository1를 만들고 Service는 이 객체를, 그리고 Controller는 이 service객체를 가져다 사용한다. Class Service1 { private final Repository1 repitory1; // repository1 객체 사용 public Service1(Repository1 repository1) { this.repository1 = new Repository1(); this.repository1 ..