검색을 위한 스펙

• 검색조건이 다양해지면 Specfication을 이용하자.

public interface Specification<T> {
	public boolean isSatisfiedby(T agg);
}

################################################################################################

public class OrdererSpec implements Specification<Order> {
	private String ordererId;

	public boolean isSatisfiedBy(Order agg) {
		return agg.getOrdererId().getMemberId().getId().equals(ordererId);
	}
}

################################################################################################

Specification<Order> ordererSpec = new OrdererSpec("madvirus");
List<Order> orders = orderRepository.findAll(ordererSpec);

• 이제 특정조건을 충족하는 애그리것을 찾으려면 원하는 스펙을 생성해서 전달하기만 하면 된다.

스펙 조합

• 스펙의 장점은 조합에 있다.
• 두 스펙을 AND나 OR로 조합해서 새로운 스펙을 만들수 있고 조합한 스펙을 다시 조합할수도 있다.

Specification<Order> ordererSpec = new OrdererSpec("madvirus");
Specification<Order> ordererDateSpec = new OrdererDateSpec(fromDate, toDate);
AndSpec<T> spec = new AndSpec(ordererSpec, orderDateSpec);

################################################################################################

List<Order> orders = orderRepository.findAll(spec);

• 여러 스펙을 하나로 만들어서 리포지토리에 전달할수 있다.

JPA를 위한 스펙 구현

• 위의 두가지 예는 모두 애그리것을 조회한다음에 스펙을 이용해 걸러내는것이였다.
• 하지만 이 방식은 속도에 문제가 있다.
• 애그리것이 10만개인경우 10만개 데이터를 DB에서 메모리로 로딩한 뒤에 다시 10만개 객체를 루프돌면서 스펙을 검사하는데 이런 경우 성능이 무지하게 느릴것이다.
• 실제 구현에서는 쿼리의 where 절에 조건을 붙여서 필요한 데이터를 걸러야 한다

JPA 스펙 구현

public interface Specification<T> {
	Predicate toPredicate(Root<T> root, CriteriaBuilder db);
}

################################################################################################

public class OrdererSpec implements Specification<Order> {
	private String ordererId;

	public Predicate toPredicate(Root<Order> root, CriteriaBuilder cb) {
		return cb.equal(root.get(Order_.orderer)
											.get(Orderer_.memberId).get(MemberId_.id),
										ordererId);
	}
}

################################################################################################

Specification<Order> ordererSpec = new OrdererSpec("madvirus");
List<Order> orders = orderRepository.findAll(ordererSpec);

• 응용서비스는 원하는 스펙을 생성하고 리포지토리에 전달해서 필요한 애그리것을 검색하면 된다.
• Order_.orderer의 Order_클래스는 JPA의 정적 메타 모델을 정의한 코드다. (p149 그림)
• Spec 구현 클래스를 개별적으로 만들지 않고 별도의 클래스에 스펙 생성 기능을 모아도 된다.

public class OrderSpecs {
	public static Specification<Order> orderer(String ordererId) {
		return (root, cb) -> cb.equal(
			root.get(Order_.orderer).get(Orderer_.memberId).get(MemberId_.id),
			ordererId);
		}

	public static Specification<Order> between(Date from, Date to) {
		return (root, cb) -> cb.between(root.get(Order_.orderDate), from, to);
	}
}

AND/OR 스펙 조합을 위한 구현

• AND SPEC

public class AndSpecification<T> implements Specification<T> {
    private List<Specification<T>> specs;

    public AndSpecification(Specification<T> ... specs) {
        this.specs = Arrays.asList(specs);
    }

    @Override
    public Predicate toPredicate(Root<T> root, CriteriaBuilder cb) {
        Predicate[] predicates = specs.stream()
                .map(spec -> spec.toPredicate(root, cb))
                .toArray(size -> new Predicate[size]);
        return cb.and(predicates);
    }
}

• OR SPEC

public class OrSpecification<T> implements Specification<T> {
    private List<Specification<T>> specs;

    public OrSpecification(Specification<T>... specs) {
        this.specs = Arrays.asList(specs);
    }

    @Override
    public Predicate toPredicate(Root<T> root, CriteriaBuilder cb) {
        Predicate[] predicates = specs.stream()
                .map(spec -> spec.toPredicate(root, cb))
                .toArray(Predicate[]::new);
        return cb.or(predicates);
    }
}

• SPEC 생성 팩토리 클래스

public class Specs {
    public static <T> Specification<T> and(Specification<T> ... specs) {
        return new AndSpecification<>(specs);
    }

    public static <T> Specification<T> or(Specification<T> ... specs) {
        return new OrSpecification<>(specs);
    }
}

• AND OR 조합

public interface Specification<T> {
    Predicate toPredicate(Root<T> root, CriteriaBuilder cb);
}

스펙을 사용하는 JPA 리포지터리 구현

		public interface OrderRepository {
		    List<Order> findAll(Specification<Order> spec, String ... orders);
		}

		@Override
    public List<Order> findAll(Specification<Order> spec, String ... orders) {
        CriteriaBuilder cb = entityManager.getCriteriaBuilder();
        CriteriaQuery<Order> criteriaQuery = cb.createQuery(Order.class);
        Root<Order> root = criteriaQuery.from(Order.class);
        Predicate predicate = spec.toPredicate(root, cb);
        criteriaQuery.where(predicate);
        if (orders.length > 0) {
            criteriaQuery.orderBy(JpaQueryUtils.toJpaOrders(root, cb, orders));
        }
        TypedQuery<Order> query = entityManager.createQuery(criteriaQuery);
        return query.getResultList();
    }

• 검색 조건이 되는 루트 생성 ( Order.class ) 루트 생성후 toPredicate로 Predicate 생성

• 생성한 Predicate를 전달하기만 하면 된다.

• 리포지토리 구현 기술 의존

  • 도메인 모델은 구현 기술에 의존하지 않아야 한다.
  • 그런데 JPA용 Spec 인터페이스는 toPredicate 메소드가 이미 Root와 CreteriaBuilder에 의존하고 있다.
  • 그렇다면 SPE을 구현 기술에 완전히 중립적인 형태로 구현해서 도메인이 구현 기술에 완전히 의존하지 않도록 만들어야 할까 ?
  • 저자는 아니라고 한다. 리포지토리 구현기술에 의존하지 않는 Spec을 만드려면 많은 부분을 추상화해야 하는데 많은 노력을 요구한다.
  • Spec 구현을 추상화하기 위해 많은 노력을 기울이는 것에 비해 실제 얻는 이점은 크지 않다.
  • 이는 리포지토리 구현 기술을 바꿀 정도의 변화는 드물기 때문이다.
  • 한 애플리케이션에서 다양한 리포지토리 구현 기술을 사용하고 각 리포지토리에 동일한 스펙 인터페이스를 사용해야 하는 경우에만 스펙을 추상화하는 노력을 해야 한다.

정렬 구현