영호

들어가면서, 우테코 5기 프로젝트를 진행하면서 처음 빌더 패턴을 써봤다. 그 과정에서 하나의 객체에 대해 2가지 버전의 Builder 를 활용할 필요성이 있었는데 겪은 문제점과 해결 방법에 대해서 작성할 예정이다. 문제 상황 회원은 2가지 종류가 있다. 임시 회원 정식 회원 임시회원은 전화번호만 필요하고, 정식 회원은 현재 OAuth를 활용하기 때문에 OAuthProvider, OAuthId 가 필요하다. 추가적으로 임시회원은 임시 닉네임으로 전화번호 마지막 4자리를 사용하기 때문에 임시회원만 전화번호를 이용해 닉네임을 생성하는 작업이 필요하다. 그래서 내가 원한 것은 내가 원한 기능 Customer 객체에 회원 종류 별 Builder 메서드를 이용해 각 회원 객체를 생성할 때 개발자의 실수를 줄이고, ..

들어가면서, 우아한테크코스 레벨3를 진행하면서 모든 layer에 대해 테스트코드를 작성했다. 그 중에서도 service레이어 테스트는 @SpringBootTest, @Transactional을 이용한 테스트를 진행했다. 그 이유는 우리의 비즈니스 로직 수행 후 DB에 알맞게 데이터가 들어갔는지 확인하고 싶었기 때문이다. 하지만, RestAssured를 통한 인수테스트를 작성하는 상황에서 service레이어의 통합테스트가 필요한지에 대해 고민하다가 service레이어의 테스트 코드를 수정한 과정에 대해 기록하겠습니다. 개선 이유1 service레이어의 관심사가 무엇인지 생각해봤습니다. service레이어는 entity의 메서드, repository의 호출을 통해 요구사항에 맞는 비즈니스 로직을 수행하는 것..

들어가면서, repository단위 테스트를 작성하면서 save한 엔티티의 createdAt이 필요했는데, 해당 값이 계속 null인 문제를 해결한 과정입니다. 현재 createdAt은 @EntityListeners(AuditingEntityListener.class) 을 이용해 생성하고 있습니다. 문제 코드 @DataJpaTest class CafePolicyRepositoryTest { @Autowired private CafePolicyRepository cafePolicyRepository; @Test void 특정_시간보다_이후에_생성된_카페_리워드_정책이_없으면_빈_리스트_반환() { Cafe savedCafe = cafeRepository.save(new Cafe()); CafePolicy ..

들어가면서, 이번 프로젝트 중 만든 DTO에 isRegistered라는 boolean타입 필드가 존재했다. 나는 해당 필드에 null이 들어갈 일이 없다고 생각해 primitive type인 boolean을 사용하면서 발생한 문제와 해결 방법에 대해 쓸 예정이다. 문제점 jackson라이브러리에서 primitive type인 boolean을 쓰고 필드명에 isXXX를 사용하면 is가 자동으로 삭제된다. 그래서 만약 isSuccess라는 필드가 boolean으로 선언되어 있다면 실제 반환되는 json에는 success가 들어가게된다. 해결방법 현재 내가 알고 있는 해결방법은 3가지가 있다. @JsonProperty(value = "isXXX") @JsonProperty를 사용하면 반환되는 json의 key..

들어가면서, 관계형 데이터베이스를 사용하면서 각각의 데이터를 식별하는 기본키는 중요한 개념이다. 데이터베이스마다 기본 키를 생성해주는 방식은 다양하다. 그래서 JPA에서도 다양한 방식에 대응하기 위해 4가지 정도의 기본 키 생성전략이 존재하는데 각각의 특징에 대해서 정리하려고 한다. AUTO 해당 전략의 경우 id로 사용하려는 필드의 타입, 사용하는 데이터베이스에 따라 전략을 '알아서' 선택해주는 방식이다. 우선, id로 사용하려는 필드 타입의 경우 2가지가 있다. UUID, Numeric(Integer, Long)이 있다. UUID를 사용하는 경우 JPA는 UUIDGenerator를 이용해 기본 키를 생성해준다. 그리고, Numeric의 경우 SequenceStyleGenerator에 의해 기본 키가 ..

들어가기 앞서, 우테코 레벨2를 진행하면서 기존과는 다르게 도메인 객체를 고유하게 식별해야 되는 상황이 생겼고, 이를 해결하기 위해 구분되어야 하는 객체에 id필드가 생기게 됐습니다. 이로 인해, 도메인 객체가 데이터베이스에 종속적인 존재가 된다는 느낌을 받고, 주변 크루들과 이야기 하면서 현재 저의 주관적인 생각을 정리한 글입니다. 다른 의견이나 잘못된 내용이 있으면 언제든 피드백 해주시면 감사하겠습니다 ^.^ 결론 우선 결론부터 말하자면 필요하다가 생각합니다. 여러 인스턴스 중 유일하게 하나의 인스턴스를 식별할 필요가 있는 객체라면 식별자가 반드시 있어야된다고 생각합니다. 그 중에서도 인조키를 통한 식별자가 좋다고 생각합니다. 그리고, 정말 DB에 종속적이지 않은게 꼭 좋은거라고 생각하지 않습니다. ..

잘못된 내용이 있으면 언제든지 피드백 해주시면 감사하겠습니다 ^.^ Context Caching? Spring에서 테스트를 작성할 때 bean으로 등록한 것들을 테스트하기 위해선 Application context가 필요하다. 하지만 테스트의 독립성을 유지하기 위해 테스트마다 모든 bean으로 구성된 Application context를 만든다면 속도가 매우 느릴것입니다. 그래서 spring의 testContext는 context caching을 해줍니다. 그렇다면 어떤 기준으로 context caching하는지 알아보겠습니다. 언제 새로운 context를 만들지? 기본적으로 textContext는 재사용할 수 있다면 이미 만들어진 context를 caching해 재사용합니다. 그렇다면 언제 재사용을 할..

개요 우테코 미션을 진행하면 dao에 대해 공부하면서 dao를 적용했을 때의 장점을 생각해봤습니다. 잘못된 내용에 대해 피드백 해주시면 감사하겠습니다 ㅎㅎ DAO baeldung의 dao관련 글을 보면 아래와 같은 문구로 시작한다. The Data Access Object (DAO) pattern is a structural pattern that allows us to isolate the application/business layer from the persistence layer (usually a relational database but could be any other persistence mechanism) using an abstract API. 간단하게 요약해보면, “추상 API를 사..