part 4. 리포지터리와 모델 구현

리포지터리와 모델 구현

JPA를 이용한 리포지터리 구현

• 리포지터리 인터페이스는 다음과 같은 형식을 가져야한다.

public interface OrderRepository{
	Order findById(OrderNo no);
	void save(Order order);
}

엔티티와 벨류 매핑

• get 과 find 함수의 차이
  • get: 찾고자 하는 데이터가 없다면 throw
  • find : 찾고자 하는 데이터가 없다면 return null

밸류 컬렉션 매핑

• p 140 - table PURCHASE_ORDER 부분에서 ORDERER_ID를 가지고 있음에도 불구하고 왜 ORDER_NAME을 가지는가?
  • Order_Name은 Orderer_Name을 의미한다면 : 주문자 명을 변경하는 요구사항이 있을수 있기 때문
  • Order_Name이 순수하게 주문 이름을 의미한다면 : 이렇다할 매핑할 필드가 없음(Order.shippingInfo 정도?)
• p 140 - Orderer에서 MemberId를 호출하는 부분에서 name= ‘id’ 로 작성하는 부분에 대하여

JPA에서 @Entity와 @Embeddable로 클래스를 매핑하려면 기본 생성자를 제공해야한다

• AttributeConverter에 관하여
  • mongoDB에서도 비슷하게 사용하는 방식
  • ex)

  {
  	"translatedContents": {
  		"ko": "",
  		"en": "",
  		"ja": ""
  	}
  }
  

  import org.springframework.core.convert.converter.Converter
  import org.springframework.data.convert.WritingConverter
  
  @WritingConverter
  class I18nToDocumentConverter : Converter<I18n, Document> {
      override fun convert(source: I18n): Document {
          val obj = Document()
  				// obj 를 원하는 방식으로 수정하여 리턴해주면 됨
          return obj
      }
  }
  

• JPA에서 식별자 타입은 Serializable타입이어야 하므로 식별자로 사용할 밸류 타입은 Serializble인터페이스를 상속 받아야한다.
  • kotlin fixture와 serializable 문제

  build.gradle.kts
  
  testImplementation 'com.appmattus.fixture:fixture:{version}'
  
  // kotlin
  val fixture = kotlinFixture()
  
  every { sampleRepository.findById(any()) } returns
      fixture()
  
  val fixture = kotlinFixture {}
  

  • serializable 객체를 kotlinFixture() 를 통해 fixture<TargetObject>()로 선언하면 nullable 하지 않는 데이터도 nullable 하게 리턴된다는 문제가 있음
  • 해결방안
    • 전략을 넣을때 nullabilityStrategy속성을 NeverNullStategy로 추가한다.

  val fixture = kotlinFixture {
        nullabilityStrategy(NeverNullStrategy)
    }
  

애그리거트 로딩 전략과 영속성 전파

식별자 생성 기능

• 사용자가 직접 생성
• 도메인 로직으로 생성
• DB를 이용하여 일련번호 사용

보통의 경우 DB에서 생성해주는 id를 사용하지 않고 회사내에서 개발해서 사용한다고 함.

• 장점
  • 개발에 편리
• 단점
  • 마이그레이션이 어려움

가상면접 사례로 배우는 시스템 설계 기초 중 분산시스템을 위한 유일 ID 생성기 설계를 참고하면 트위터 스노플레이크 접근법을 통해 구현하는 것을 추천한다.