1108 - 1114

1108 - ssl

SSL이란?

SSL(Secure Socket Layer)은 암호화 기반 인터넷 보안 프로토콜이다. 인터넷 통신의 개인정보 보호, 인증, 데이터 무결성을 보장하기 위해 Netscape가 1995년 처음으로 개발했다. SSL은 현재 사용 중인 TLS 암호화의 전신이다.

SSL/TLS를 사용하는 웹사이트의 URL에는 "HTTP"대신 "HTTPS"가 있다.

SSL/TLS 작동원리

• SSL은 높은 수준의 개인정보 보호를 제공하기 위해, 웹에서 전송되는 데이터를 암호화한다. 따라서, 데이터를 가로채려는 자는 거의 해독할 수 없는 복잡한 문자만 보게 된다.
• SSL은 두 통신 장치 사이에 핸드셰이크라는 인증 프로세스를 시작하여 두 장치의 ID를 확인한다.
• SSL은 또한 데이터 무결성을 제공하기 위해 데이터에 디지털 서명하여 데이터가 의도된 수신자에 도착하기 전에 조작되지 않았다는 것을 확인하다.

SSL은 여러 번 개선되어 매번 성능이 개선되었으며, 1999년에 SSL은 TLS로 업데이트 됐다.

SSL/TLS의 중요성

• 예, 주문 과정에서 고객의 신용 카드 번호가 사용됐을떄 탈취자에게 노출되게 된다.
• 또한 SSL은 특정한 유형의 사이버 공격도 차단한다.

SSL/TLS의 차이

• SSL은 TLS(Transport Layer Security)라는 또 다른 프로토콜의 바로 이전 버전이다. 1999년 IETF는 SSL에 대한 업데이트를 제안했고, Netscape가 더 이상 참여하지 않게 되면서, 이름이 TLS로 변경되었다.

SSL인증이란?

SSL은 SSL 인증서가 있는 웹사이트만 실행할 수 있다. SSL 인증서는 웹사이트나 애플리케이션 서버가 웹에 저장하고 표시한다.

SSL 인증서에 포함된 가장 중요한 정보에 웹사이트의 공개 키가 있다. 이 공개 키 덕북에 암호화가 가능하며, 사용자의 장치는 공개 키를 보고 이를 이용하여 웹 서버와 안전한 암호화 키를 수립한다. 한편, 웹 서버에도 기밀로 유지하는 개인 키가 있다. 개인 키는 공개 키로 암호화된 데이터를 해독한다. CA(인증 기관)는 SSL 인증서 발행을 담당한다.

SSL 인증서 유형

• 단일 도메인
• 와일드카드
• 멀티 도메인
• 도메인 유효성 검사
• 조직 유효성 검사
• 확장 유효성 검사

1110 - MapStruct(맵스트럭트)

Model mapping을 아주 쉽게 해주는 라이브러리.

맵스트럭트 사용법

build.gradle

buildscript {
	ext {
		mapstructVersion = '1.3.1.Final'
	}
}

...

// Mapstruct
implementation "org.mapstruct:mapstruct:${mapstructVersion}"
annotationProcessor "org.mapstruct:mapstruct-processor:${mapstructVersion}"
testAnnotationProcessor "org.mapstruct:mapstruct-processor:${mapstructVersion}"

...

compileJava {
	options.compilerArgs = [
			'-Amapstruct.suppressGeneratorTimestamp=true',
			'-Amapstruct.suppressGeneratorVersionInfoComment=true'
	]
}

java

@Data
@AllArgsConstructor(staticName = "of")
@NoArgsConstructor
public class CarDto {
    private String name;
    private String color;
}
 
---

@Data
@AllArgsConstructor(staticName = "of")
@NoArgsConstructor
public class Car {
    private String modelName;
    private String modelColor;
}
 
---

@Mapper
public interface CarMapper {
 
    CarMapper INSTANCE = Mappers.getMapper(CarMapper.class);
 
    @Mapping(source = "name", target = "modelName")
    @Mapping(source = "color", target = "modelColor")
    Car to(CarDto carDto);
}

각각 dto, domain, mapper

public class MapstructTest {
 
    @Test
    public void test() {
        CarDto carDto = CarDto.of("bmw x4", "black");
        Car car = CarMapper.INSTANCE.to(carDto);
 
        assertEquals(carDto.getName(), car.getModelName());
        assertEquals(carDto.getColor(), car.getModelColor());
    }
}

간단한 테스트 코드

• 실제 생성된 코드

@Generated(
    value = "org.mapstruct.ap.MappingProcessor"
)
public class CarMapperImpl implements CarMapper {
 
    @Override
    public Car to(CarDto carDto) {
        if ( carDto == null ) {
            return null;
        }
 
        Car car = new Car();
 
        car.setModelName( carDto.getName() );
        car.setModelColor( carDto.getColor() );
 
        return car;
    }
}

하나의 객체로 합치기

• 여러 객체의 필드값을 하나의 객체로 합치기가 가능하다. 특별히 다른 옵션을 넣는 것은 아니다.

@Data
@AllArgsConstructor(staticName = "of")
@NoArgsConstructor
public class UserDto {
    private String name;
}

--- 

@Data
@AllArgsConstructor(staticName = "of")
@NoArgsConstructor
public class AddressDto {
    private String si;
    private String dong;
}
 
---

@Mapper
public interface UserInfoMapper {
 
    UserInfoMapper INSTANCE = Mappers.getMapper(UserInfoMapper.class);
 
    @Mapping(source = "user.name", target = "userName")
    @Mapping(source = "address.si", target = "si")
    @Mapping(source = "address.dong", target = "dong")
    UserInfo to(UserDto user, AddressDto address);
}
 
--- 

@Generated(
    value = "org.mapstruct.ap.MappingProcessor"
)
public class UserInfoMapperImpl implements UserInfoMapper {
 
    @Override
    public UserInfo to(UserDto user, AddressDto address) {
        if ( user == null && address == null ) {
            return null;
        }
 
        UserInfo userInfo = new UserInfo();
 
        if ( user != null ) {
            userInfo.setUserName( user.getName() );
        }
        if ( address != null ) {
            userInfo.setDong( address.getDong() );
            userInfo.setSi( address.getSi() );
        }
 
        return userInfo;
    }
}

이미 생성된 객체에 매핑

• 새로운 인스턴스를 생성하는 것이 아니라, 기존에 이미 생성되어 있는 객체에 매핑이 필요한 경우

@Mapper
public interface UserInfoMapper {
 
    UserInfoMapper INSTANCE = Mappers.getMapper(UserInfoMapper.class);
 
    @Mapping(source = "user.name", target = "userName")
    @Mapping(source = "address.si", target = "si")
    @Mapping(source = "address.dong", target = "dong")
    void write(UserDto user, AddressDto address, @MappingTarget UserInfo userInfo);
}
 
@Generated(
    value = "org.mapstruct.ap.MappingProcessor"
)
public class UserInfoMapperImpl implements UserInfoMapper {
 
    @Override
    public void write(UserDto user, AddressDto address, UserInfo userInfo) {
        if ( user == null && address == null ) {
            return;
        }
 
        if ( user != null ) {
            userInfo.setUserName( user.getName() );
        }
        if ( address != null ) {
            userInfo.setDong( address.getDong() );
            userInfo.setSi( address.getSi() );
        }
    }
}

타입 변환

• 대부분의 암시적인 자동 형변환이 가능하다. (Integer -> String ...) 다음은 조금 유용한 기능이다.

@Mapper
public interface CarMapper {
 
    @Mapping(source = "price", numberFormat = "$#.00")
    CarDto carToCarDto(Car car);
 
    @IterableMapping(numberFormat = "$#.00")
    List<String> prices(List<Integer> prices);
}

Source, Target mapping policy

• 매핑될 필드가 존재하지 않을 때, 엄격한 정책을 가져가기 위한 기능을 제공한다.

@Data
@AllArgsConstructor(staticName = "of")
@NoArgsConstructor
public class Car {
    private String modelName;
    private String modelColor;
    private String modelPrice;
    private String description;
}
 
@Data
@AllArgsConstructor(staticName = "of")
@NoArgsConstructor
public class CarDto {
    private String name;
    private String color;
    private Integer price;
}
 
@Mapper(unmappedTargetPolicy = ReportingPolicy.ERROR)
public interface CarMapper {
 
    CarMapper INSTANCE = Mappers.getMapper(CarMapper.class);
 
    @Mapping(source = "name", target = "modelName")
    @Mapping(source = "color", target = "modelColor")
    @Mapping(source = "price", target = "modelPrice", numberFormat = "$#.00")
    Car to(CarDto carDto);
 
}

위 코드는 타겟이 되는 오브젝트 필드에 대한 정책을 가져간다. Car 클래스에는 description 필드가 있는데, CarDto 클래스에는 해당 필드가 존재하지 않기 때문에 컴파일시 컴파일에러가 발생한다.(ERROR, IGNORE, WARN 정책 존재) 만약 특정 필드는 해당 정책을 피하고 싶다면 아래와 같이 어노테이션하나를 달아준다.

@Mapper(unmappedTargetPolicy = ReportingPolicy.ERROR)
public interface CarMapper {
 
    CarMapper INSTANCE = Mappers.getMapper(CarMapper.class);
 
    @Mapping(source = "name", target = "modelName")
    @Mapping(source = "color", target = "modelColor")
    @Mapping(source = "price", target = "modelPrice", numberFormat = "$#.00")
    @Mapping(target = "description", ignore = true)
    Car to(CarDto carDto);
 
}

null 정책

• Source가 null이거나 혹은 Source의 특정 필드가 null일때 적용가능한 정책이 존재한다.

@Mapper(
        unmappedTargetPolicy = ReportingPolicy.ERROR,
        nullValueMappingStrategy = NullValueMappingStrategy.RETURN_DEFAULT
)
public interface CarMapper {
 
    CarMapper INSTANCE = Mappers.getMapper(CarMapper.class);
 
    @Mapping(source = "name", target = "modelName")
    @Mapping(source = "color", target = "modelColor")
    @Mapping(source = "price", target = "modelPrice", numberFormat = "$#.00")
    @Mapping(target = "description", ignore = true)
    Car to(CarDto carDto);
 
}

위 코드는 Source 오브젝트가 null일때, 기본생성자로 필드가 비어있는 Target 오브젝트를 반환해준다.

@Mapper(
        unmappedTargetPolicy = ReportingPolicy.ERROR,
        nullValueMappingStrategy = NullValueMappingStrategy.RETURN_NULL
)
public interface CarMapper {
 
    CarMapper INSTANCE = Mappers.getMapper(CarMapper.class);
 
    @Mapping(source = "name", target = "modelName")
    @Mapping(source = "color", target = "modelColor")
    @Mapping(source = "price", target = "modelPrice", numberFormat = "$#.00")
    @Mapping(
            source = "description", 
            target = "description", 
            ignore = true,
            nullValuePropertyMappingStrategy = NullValuePropertyMappingStrategy.SET_TO_DEFAULT
    )
    Car to(CarDto carDto);
 
}

위 코드는 각 필드에 대해 null정책을 부여한다. 만약 SET_TO_DEFAULT로 설정하면, List 일때는 빈 ArrayList를 생성해주고, String은 빈문자열, 특정 오브젝트라면 해당 오브젝트의 기본 생성자 등으로 기본값을 생성해준다.

특정 필드 매핑 무시

• 특정 필드는 매핑되지 않길 원한다면 @Mapping 어노테이션에 ignore = true 속성을 넣어준다.

@Mapper(
        unmappedTargetPolicy = ReportingPolicy.ERROR,
        nullValueMappingStrategy = NullValueMappingStrategy.RETURN_NULL
)
public interface CarMapper {
 
    CarMapper INSTANCE = Mappers.getMapper(CarMapper.class);
 
    @Mapping(source = "name", target = "modelName")
    @Mapping(source = "color", target = "modelColor")
    @Mapping(source = "price", target = "modelPrice", numberFormat = "$#.00")
    @Mapping(target = "description", ignore = true)
    Car to(CarDto carDto);
 
}
 
public class MapstructTest {
 
    @Test
    public void test() {
        CarDto carDto = CarDto.of(
                "bmw x4",
                "black",
                10000,
                "description");
        Car car = CarMapper.INSTANCE.to(carDto);
        System.out.println(car.toString());
    }
}
 
result =>
 
Car(modelName=bmw x4, modelColor=black, modelPrice=$10000.00, description=null)

매핑 전처리, 후처리

• 매핑하기 이전과 매핑 이후 특정 로직을 주입시킬 수 있다.

@Mapper(
        unmappedTargetPolicy = ReportingPolicy.ERROR,
        nullValueMappingStrategy = NullValueMappingStrategy.RETURN_NULL,
        componentModel = "spring"
)
public abstract class CarMapper {
 
    @BeforeMapping
    protected void setColor(CarDto carDto, @MappingTarget Car car) {
        if (carDto.getName().equals("bmw x4")) {
            car.setModelColor("red");
        } else {
            car.setModelColor("black");
        }
 
    }
 
    @Mapping(source = "name", target = "modelName")
    @Mapping(target = "modelColor", ignore = true)
    @Mapping(source = "price", target = "modelPrice", numberFormat = "$#.00")
    public abstract Car to(CarDto carDto);
 
    @AfterMapping
    protected void setDescription(@MappingTarget Car car) {
        car.setDescription(car.getModelName() + " " + car.getModelColor());
    }
}
 
<Generate Code>
 
@Generated(
    value = "org.mapstruct.ap.MappingProcessor"
)
@Component
public class CarMapperImpl extends CarMapper {
 
    @Override
    public Car to(CarDto carDto) {
        if ( carDto == null ) {
            return null;
        }
 
        Car car = new Car();
 
        setColor( carDto, car );
 
        car.setModelName( carDto.getName() );
        if ( carDto.getPrice() != null ) {
            car.setModelPrice( new DecimalFormat( "$#.00" ).format( carDto.getPrice() ) );
        }
        car.setDescription( carDto.getDescription() );
 
        setDescription( car );
 
        return car;
    }
}

전처리와 후처리를 위한 메서드는 private를 사용해서는 안된다. 그 이유는 generate된 코드에 전, 후 처리 메서드가 들어가는 것이 아니라 추상 클래스에 있는 메서드를 그대로 사용하기 때문이다.

• 공식 레퍼런스 https://mapstruct.org/documentation/stable/reference/html/

1112 - custom exception 장단점

표준 예외 사용시 장점

1. 예외 메시지로도 충분히 의미를 전달할 수 있다.

• 유효하지 않은 입력값에 대한 예외 같은 경우 자바에서 정의해 놓은 IllegalArgumentException을 사용하고 메시지만 예외사항에 맞게 재정의해준다면 충분히 그 의미를 파악할 수 있다.

2. 표준 예외를 사용하면 가독성이 높아진다.

• 인수로 부적절한 값이 들어올 때 던지는 예외인 IllegalArgumentException, 일을 수행하기에 적합하지 않은 상태의 객체인 경우 던지는 예외인 IllegalStateException, 요청받은 작업을 지원하지 않는 경우에 던지는 예외인 UnsupportedOperationException 등, 우리는 이미 익숙하고, 쓰임에 대해 잘 알고있는 예외들이 많다.
  이런 예외들이 아닌 처음 보는 예외들은 당연히 구체적인 쓰임을 잘 모른다. 이런 이유로 낯선 예외보다는 익숙한 예외를 마주치는 것이 당연히 가동성이 높을 수 밖에 없다.
  또한, 낯선 예외를 만났을 땐, 당연하게도 그 커스텀 익셉션을 파악하는 작업이 따라온다. 이 또한 비용이 될 수 있다.
  표준 예외에 대한 쓰임은 공식문서를 참고하면 된다. https://docs.oracle.com/javase/8/docs/api/?java/lang/RuntimeException.html

3. 일일히 예외 클래스를 만들다보면 지나치게 커스텀 예외가 많아질 수 있다.

• 많은 domain이 생기고 도메인 별 정의된 custom Exception들이 생길 경우 지나치게 많아질 수 있다. 이 디렉토리와 클래스를 관리하는 것 역시 일이며, 지나치게 많아진다면 메모리 문제도 발생할 수 있고, 클래스 로딩에도 시간이 더 소요될 가능성이 있다.

커스텀 예외 사용시 장점

사용자 정의 예외가 필요하다.

• Spring의 @Valid 어노테이션은 예외 상황에서 MethodArgumentNotValidException을 발생시킨다. 해당 예외의 패키지 구조는 org.springframework.web.bind.MethodArgumentNotValidException 으로 Spring에서 만든 사용자 정의 예외다.

1. 이름으로도 정보 전달이 가능하다.

• NoSuchElementException 만으로는 어떤 요소가 없는지 알 수 없다. 하지만, PostNotFoundException이 발생했따면, Post를 찾는 요청을 보냈지만 해당 요소가 없다는 상황을 유추할 수 있을 것이다.
  이처럼 Custom Exception은 이름을 통해 일차적으로 예외 발생 상황에 대해 유추할 수 있는 정보를 제공한다.

2. 상세한 예외 정보를 제공할 수 있다.

• 컬렉션의 범위를 벗어난 index 접근 요청이 생겼다고 가정했을때, 기존의 예외에선 IllegalArgumentException이나 IndexOutOfBoundsException을 후보로 생각해볼 수 있을 것이다. 예외 메시지로는 "범위를 벗어났습니다." 정도면 적당하다.

if (index >= arr.length) {
  throw new IndexOutOfBoundsException("범위를 벗어났습니다.");
}

• 하지만 전체 범위가 얼마인지, 요청한 index가 몇인지 파악하기 우해서는 프로그래머가 직접 디버깅하거나 정보를 담은 메시지를 만들어줘야 한다. 디버그르류 통해 직접 정보를 찾아내는 행위는 썩 좋은 일이 아니다. 개발 과정에 피로함만 늘어간다. 메시지는 단 한 곳에서만 발생하는 예외라면 상관없지만 여러 곳에서 발생한다면 리팩토링하기가 힘들어 질 것이다.
  이러한 상황에서 사용자 정의 예외는 좋은 해결책이 될 수 있다.

public class IllegalIndexException extends IndexOutOfBoundsException {
	private static final String message = "범위를 벗어났습니다.";

	public IllegalIndexException(List<?> target, int index) {
		super(message + " size: "  + target.size() + " index: " + index);
	}
}

• 예를 보면 요청 받은 컬렉션의 최대 범위가 어디까지인지, 요청한 index는 몇인지 확인 가능하다. try/catch를 통해 발생한 예외를 붙잡아 새로 만든 예외를 던져도 되고, 기존 예외가 발생하기 전에 index를 검사해 새로 맏는 예외를 직접 발생시켜도 괜찮다.
  전달하는 정보의 수정이 필요할 때는 IllegalIndexException 클래스를 수정하면 된다. 같은 예외를 발생시키는 모든 상황에 적용될 것이다.

3. 예외에 대한 응집도가 향상된다.

• 클래스를 만드는 행위는 관련 정보를 해당 클래스에서 최대한 관리하겠다는 이야기다.
  표준예외와 메시지로도 충분히 정보를 전달할 수 있지만, 전달하는 정보의 양이 많아지거나 여러곳에서 발생하는 예외라면 책임소재가 불분명해진다.
  사실 정적 메소드를 담은 유틸성 클래스로도 충분히 표준 예외를 사용하면서 이문제를 해결할 수 도 있지만 사용자 정의 예외를 사용한다면 객체의 책임이 분리된 깔끔한 코드를 얻을 수 있다.

4. 예외 발생 후처리가 용이하다.

• 예외는 상속 관계에 있기 때문에, Exception이나 RuntimeException을 잡아두면 프로그램 내에서 발생하는 거의 모든 예외에 대해 처리가 가능하다. 하지만 이는 프로그래머가 의도하지 않은 예외까지 모두 잡아내 혼란을 야기할 수 있다.
  재사용성이 높은 것은 표준 예외들의 장점이다. 하지만 그 장점 때문에 발생 위치를 정확하게 파악하기 힘들다는 단점도 생긴다.

5. 예외 생성 비용을 절감한다.

• 자바에서 예외를 생성하는 행위는 생각보다 많은 비용이 소모된다. 바로 stack trace 때문이다.
  stack trace는 예외 발생 시 call stack에 있는 메소드 리스트를 저장한다. 이를 통해 예외가 발생한 정확한 위치를 파악할 수 있다. 하지만 try/catch나 Advice를 통해 예외를 처리한다면 해다 예외의 stack trace는 사용하지 않을 때가 많다. 비용을 들여 만들었다지만 사용하지 않고 사라지는 형태, 너무나도 비요율적이다.

stack trace의 생성은 예외의 부모 클래스 중 Throwable의 fillInStackTrace() 메소드를 통해 이루어진다. 사용자 정의 예외는 해당 메소드를 Override 함으로 stack trace의 생성 비용을 줄일 수 있다. 필요하다면 짧게 일부만을 생성할 수도, 아예 생성하지 않을 수도 있다.

@Override
public synchronized Throwable fillInStackTrace() {
	  return this;
}

public class CustomException extends RuntimeException {
	  public static final CustomException CUSTOM_EXCEPTION = new CustomException("대충 예외라는 내용");
	  //...
}

• 만일 구현해 낸 Custom Exception이 stack trace도 갖지 않고, 상황에 따라 정보를 다르게 주는 예외가 아니라 단순하게 메세지만 넘겨준다면 해당 예외를 캐싱해 두는 것도 비용 절감의 방법이다.

1113 - 임베디드 타입(embedded type)

임베디드 타입(복합 값 타입)

새로운 값 타입을 직접 정의해서 사용할 수 있따. JPA에서는 이것을 임베디드 타입(embedded type)이라 한다. 중요한 것은 직접 정의한 임베디드 타입도 int, String 처럼 값 타입이다.

예제

• 임베디드 타입을 사용하지 않았을 때

@Entity
public class Member {
  
  @Id @GeneratedValue
  private Long id;
  private String name;
  
  // 근무 기간
  @Temporal(TemporalType.DATE)
  Date startDate;
  @Temporal(TemporalType.DATE)
  Date endDate;
  
  // 집 주소 표현
  private String city;
  private String street;
  private String zipcode;
  // ...
}

• 임베디드 타입 사용

@Entity
public class Member {
  
  @Id @GeneratedVAlue
  private Long id;
  private String name;
  
  @Embedded
  private Period workPeriod;	// 근무 기간
  
  @Embedded
  private Address homeAddress;	// 집 주소
}

---

@Embeddable
public class Peroid {
  
  @Temporal(TemporalType.DATE)
  Date startDate;
  @Temporal(TemporalType/Date)
  Date endDate;
  // ...
  
  public boolean isWork (Date date) {
    // .. 값 타입을 위한 메서드를 정의할 수 있다
  }
}

---

@Embeddable
public class Address {
  
  @Column(name="city") // 매핑할 컬럼 정의 가능
  private String city;
  private String street;
  private String zipcode;
  // ...
}

임베디드 타입 사용 방법

• @Embeddable : 값 타입을 정의하는 곳에 표시
• @Embedded : 값 타입을 사용하는 곳에 표시
• 임베디드 타입은 기본 생성자가 필수

임베디드 타입을 포함한 모든 값 타입은 엔티티의 생명주기에 의존하므로 엔티티와 임베디드 타입 관계를 UML로 표현 하면 컴포지션(composition) 관계가 된다.

하이버네이트는 임베디드 타입을 컴포넌트(components)라 한다.

<회원-컴포지션 관계 UML (출처: 김영한님 강의)>

임베디드 타입의 장점

• 재사용
• 높은 응집도
• Period 객체의 isWork() 메서드처럼 해당 값 타입만 사용하는 의미있는 메서드를 만들 수 있다.

임베디드 타입과 테이블 매핑

<임베디드 타입을 사용한 회원-테이블 매핑 (출처: 김영한님 강의)>

임베디드 타입은 엔티티의 값일 뿐이다. 따라서 값이 속한 엔티티의 테이블에 매핑되며, 임베디드 타입을 사용하기 전과 후에 매핑되는 테이블은 동일하다.

임베디드 타입 덕분에 객체와 테이블을 아주 세밀하게(fine-grained) 매핑하는 것이 가능하다. 잘 설계한 ORM 애플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많다.

임베디드 타입과 연관관계

임베디드 타입은 값 타입을 포함하거나 엔티티를 참조할 수 있다.

@Entity
public class Member {
  
  @Embedded
  Address address;	// 임베디드 타입 포함
  @Embedded
  PhoneNumber phoneNumber;	// 임베디드 타입 포함

  // ...
}


@Embeddable
public class Address {
  String street;
  String city;
  String state;
  @Embedded
  Zipcode zipcode; // 임베디드 타입 포함
}


@Embeddable
public class Zipcode {
  String zip;
  String plusFour;
}


@Embeddable
public class PhoneNumber {
 
  String areaCode;
  String localNumber;
  
  @ManyToOne
  PhoneServiceProvider provider;	// 엔티티 참조
}


@Entity
public class PhoneServiceProvider {
  @Id
  String name;
 	// ...
}

값 타입인 Address가 값 타입인 Zipcode를 포함하고, 값 타입인 PhoneNumber가 엔티티 타입인 PhoneServiceProvider를 참조한다.

@AttributeOverride: 속성 재정의

임베디드 타입에 정의한 매핑정보를 재정의하려면 엔티티에 @AttributeOverride를 사용하면 된다.

// 같은 임베디드 타입을 가지고 있는 회원
@Entity
public class Member {
  
  @Id @GeneratedValue
  private Long id;
  private String name;
  
  @Embedded
  Address homeAddress;
  
  @Embedded
  Address companyAddress;
}

위 코드의 문제점은 테이블에 매핑하는 컬럼명이 중복된다. 이떄는 아래와 같이 @AttributeOberrides를 사용해서 매핑정보를 재정의해야 한다.

@Entity
public class Member {
  
  @Id @GeneratedValue
  private Long id;
  private String name;
  
  @Embedded
  Address homeAddress;
  
  @Embedded
  @AttributeOverrides({
    @AttributeOverride(name="city", column=@Column(name="COMPANY_CITY")),
    @AttributeOverride(name="street", column=@Column(name="COMPANY_STREET")),
    @AttributeOverride(name="zipcode", column=@Column(name="COMPANY_ZIPCODE"))
  })
  Address companyAddress;
}

// 생성된 테이블
------------------------------
CREATE TABLE MEMBER (
	COMPANY_CITY varchar(255),
  COMPANY_STREET varchar(255),
  COMPANY_ZIPCODE varchar(255),
  city varchar(255),
  street varchar(255),
  zipcode varchar(255),
  ...
)
------------------------------

@AttributeOverrides는 엔티티에 설정해야 한다. 임베디드 타입이 임베디드 타입을 가지고 있어도 엔티티에 설정해야 한다.

임베디드 타입과 Null

임베디드 타입이 null이면 매핑한 컬럼 값은 모두 null이 된다.