아장아장거리면서 주책부리는 블로그

private static final PageRequest page = PageRequest.of(0, 3); search 하나로 더욱 다양한 기능을 만들 방법을 생각해보았다. 페이징을 추가하자 RequestParam방식으로 페이지를 입력받아 몇 번째 페이지인지를 알려줄 것이다. 한 페이지당 기본으로 10개정도의 결과를 가지게 반환시킬 계획이다. 멤버 조회시 아이디, 닉네임, 이메일이 나오므로 총 30줄정도가 나올 것 이므로 10개 정도가 적당하다는 생각이 들었다. contains를 동적으로 추가하자 enum클래스를 만들어 RequestParam으로 검색방식을 정확한 검색인지, 혹은 검색하는 문구가 포함된 값을 구하는지를 정하게 할 것이다. 이전에 만들었던 ~~Eq메서드에 enum타입의 값을 받아 만약 ..

이번 프로젝트에서 jwt토큰을 이용해 로그인을 하게 하려고 했다. 이를 위해서 두가지 과정이 필요하다 로그인 요청을 이용해 Authentication을 만든다. 로그인 요청을 validate한다 요청의 아이디와 비밀번호를 가지고 UsernamePasswordAuthenticationToken을 만들어준다. 토큰에서 authentication을 뽑아온다. Authentication을 가지고 토큰을 만들고, 토큰 응답을 반환한다. TokenProdivder에서 Authentication을 가지고 TokenDto를 생성해준다. authentication에서 name(아이디)를 key, TokenDto의 refreshToken을 value로 가지는 RefreshToken객체를 만들어 저장한다. 이를 TokenR..

사실 검색에 대한 테스트코드를 만드는 것은 간단하다. 리포지토리 테스트코드에서, 기능들을 그대로 가져다 쓰는 것과 동일하다 . @BeforeEach void createData() { for(int index = 0; index < 10; index++){ RegisterRequestDto registerRequestDto = RegisterRequestDto.builder() .username("testUser" + index) .nickname("test" + index) .email("test" + index + "@test.com") .password("password" + index) .passwordCheck("password" + index) .build(); memberService.reg..

일단 정보 수정을 수행하는 로직의 테스트부터 만들어볼 것이다. 닉네임 수정 닉네임 중복으로 예외처리 정상적으로 수정 이메일 수정 이메일 중복으로 예외처리 정상적으로 수정 비밀번호 수정 기존 비밀번호와 동일해 예외처리 입력한 비밀번호 2가지가 서로 불일치 정상적으로 수정 이렇게 총 3가지의 수정 메서드와, 각 메서드당 2(비밀번호는 3)가지 경우가 생기게 된다. 결국 7가지 테스트를 만들어두고, 이에 대해 기능을 수행하는 메서드를 만들어보려고 한다. private Member makeMember(String index){ RegisterRequestDto registerRequestDto = RegisterRequestDto.builder() .username("test" + index) .nickname..

이전에 만든 테스트가 동작하게, 하나씩 만들어보아야 겠다. 일단, 아이디 중복을 처리했을 때 동작하는지 코드를 만들어보자. private void validateUsername(String username){ if(memberRepository.findByUsername(username).isPresent()) throw new UsernameAlreadyInUseException(); } 이런식으로 중복이 되는 것을 닉네임, 이메일에도 처리해주었다. validateUsername(registerRequestDto.getUsername()); validateNickname(registerRequestDto.getNickname()); validateEmail(registerRequestDto.getEma..

이제 리포지토리에서 구현했던 기능들과, Member 도메인 로직을 이용해, 멤버의 서비스를 구현할 것이다. 도메인 로직과 리포지토리의 기능들을 이용해, 실제 멤버가 동작해야 할 비즈니스 로직을 만들어볼 것이다. 구조를 생각해보기 위해 회원가입을 생각해보자. 입력을 받는다. 중복 계정을 조회한다. 중복 닉네임을 조회한다. 중복 이메일을 조회한다. 비밀번호를 2번 입력받았을 때 이를 확인한다. 비밀번호를 암호화 시켜준다. 입력으로 Member를 생성해준다. MemberRepository.save해준다. 이런 방식으로 이루어진다. 그렇다면, 회원가입을 했을 때 문제가 생길 결과는 무엇일까? 입력값이 다른 회원과 중복될 때, 예외처리된다(아이디, 닉네임, 이메일 예외를 모두 따로 설정해준다) 비밀번호 입력이 서..

이전에 만든 검색기능을 조금 더 최적화 시켜야 할 필요가 있다. 이러한 생각이 든 이유는, 멤버를 검색하는 기능에서 엔티티가 바로 클라이언트 단으로 나가도 괜찮을까? 일반 사용자가 다른 사용자를 검색했을 때 나와야 할 것은 기본적인 정보(아이디, 닉네임, 이메일)외에 다른 게 없는데 굳이 많은 데이터를 끌어올 필요가 있을까? 정도였다. 그래서, 이번엔 바로 dto로 데이터를 검색시키는 방법으로 최적화를 시키려고 한다. 일단, @QueryProjection public SearchMemberDto(String username, String nickname, String email) { this.username = username; this.nickname = nickname; this.email = ema..

저번에 만든 QueryDsl을 어디에 써먹는지, 이제 적어볼 생각이다. 저번에 만든 MemberCustomRepositoryImpl의 search를 전부 지워버렸다. 이후, QueryDsl을 위해 만들어야 할 것들을 정리해보았다. JPAQueryFactory 인스턴스를 초기화 하는 생성자 search : 아이디, 닉네임, 이메일을 가지고 검색을 수행한다. null값은 스킵한다. usernameEq : 아이디가 null이면 null을 반환하고, 아니면 쿼리문을 반환한다. nicknameEq : 닉네임이 null이면 null을 반환하고, 아니면 쿼리문을 반환한다. emailEq : 이메일이 null이면 null을 반환하고, 아니면 쿼리문을 반환한다. 이제 이걸 만들어보자. public class Member..

실질적으로 지난 블로그 공백기(!) 중에 제일 공부하기 잘했다고 생각이 드는, queryDsl을 설정해줄 것이다. 일단 build.gradle에 이러한 의존성과, 설정 주입을 해주어야 한다. buildscript { ext { queryDslVersion = "5.0.0" } } plugins { id 'java' id 'org.springframework.boot' version '2.7.0' id 'io.spring.dependency-management' version '1.0.11.RELEASE' id "com.ewerk.gradle.plugins.querydsl" version "1.0.10" } 제일 위에 queryDslVersion을 적어주고, plugins에 마지막줄에 queryDsl을 넣..

저번에 만든 멤버 리포지토리를 가지고, 이제 새로운 기능들을 주입시켜볼 것이다. 기본적으로 메서드의 이름을 가지고 생성, 조회, 삭제를 할 수 있다. 그러면 조회하는 요소를 이름, 이메일, 닉네임중에 몇개를 골라서 수행하는, 동적 방식의 조회는 어떻게 할까? 이걸 JPQL(노가다)로 한번 만들어보고, 테스트를 수행시켜보고, QueryDSL을 통해 업그레이드 시켜볼 계획이다. 일단, 검색을 시켜줄 dto와 예외처리부터 만들었다. @Data public class SearchMemberDto { private String username; private String nickname; private String email; public SearchMemberDto(String username, String n..