User 엔티티명 Customer로 수정, Jpa Auditing 적용

생각해보니 RoleType 이라는 속성도 의미가 없었다.

비회원은 User 엔티티 속성이 모두 null이여야 한다. 

 

비회원, 회원, 관리자를 단순히 하나의 필드로 구분할게 아니라 완전히 다른 개체로 분리해야 하는건 아닌가라는 생각이 들었다.

그래서 일단 지금은 User -> Customer 로 바꾸고 RoleType 속성은 삭제하자. 비회원과 관리자는 일단 미뤄둔다.

 

import ...

@Getter @ToString
@NoArgsConstructor
@Entity
@EntityListeners(value = AuditingEntityListener.class)
public class Customer {

    @Id @GeneratedValue(strategy = GenerationType.SEQUENCE)
    @Column(name = "CUSTOMER_ID")
    private Long id;

    @Column(nullable = false, unique = true)
    private String email;

    @Column(nullable = false)
    private String password;

    @Embedded
    private Address address;

    @CreatedDate
    private LocalDateTime createdDatetime;

    @LastModifiedDate
    private LocalDateTime modifiedDatetime;

    @Builder
    public Customer(String email, String password, Address address) {
        this.email = email;
        this.password = password;
        this.address = address;
    }

    public void update(String email, String password, Address address) {
        this.email = email;
        this.password = password;
        this.address = address;
    }
}

 위는 수정한 Customer 엔티티의 코드다.

 

그리고 엔티티 생성일과 수정일을 엔티티의 이벤트를 감지해서 자동으로 수정하는 코드가 추가됐다.

JPA Auditing 이라는 건데.

 

엔티티의 변경 이벤트를 체크해 @Created...  @LastModifed.. 같은 애너테이션이 붙은 필드에 적절한 처리를 한다.

 

이걸 적용하기 전에는 엔티티 생명 주기와 관련한 콜백 메서드를 이용해서 위를 구현했었는데, 구동방식은 같아 보인다.

(스프링은 @PostPersist, @PostModified ... 와 같은 생명 주기와 관련된 메서드에 붙일 수 있는 애너테이션을 지원한다.)

그래도 이 방식이 훨씬 가독성 면에서 좋은듯.

 

다른 분들의 코드들처럼 날짜를 클래스로 아예 분리시켜 상속시킬까도 생각했으나 ...

흠 상속을 이용하기는 좀 꺼려지긴 한다. 자바에선 상속을 한번 밖에 적용할 수 없기 때문.

 

일단은 그냥 필드에 두고 필요하다면 분리하도록 하자.