let's placeBid

더 읽 기
이 예 는 매우 낡 았 다. 이전의 Domain Model 논쟁 에서 광범 위 하 게 인용 되 었 다. (참조:http://www.iteye.com/topic/11712）。볶음밥 다시 볶 을 게 요.
이 Domain 은 이렇게 간략화 할 수 있다.

public class Item {
  private Set bids = new HashSet();
}

public class Bid {
  private User bidder;
  private int amount;
}

지금 우 리 는 placeBid 라 는 행동 을 추가 해 야 한다.그래서 우 리 는 다음 과 같은 빈혈 코드 를 쓸 수 있다.

    Bid currentMaxBid = itemDAO.getMaxBid(itemId);
    Item item = itemDAO.findById(itemId, true);
    if (currentMaxBid != null && bidAmount <= currentMaxBid.getAmount()) {
        throw new BizException("Bid too low.");
    }
    Bid newBid = new Bid(this, bidder, bidAmount);
    item.getBids().add(bid);
    itemDao.save(item);

이런 코드 에 무슨 문제 가 있 습 니까?나 는 더 많은 수요 가 없고 시스템 규모 가 크 지 않 은 상황 에서 이런 결함 을 증명 할 강력 한 증 거 를 제시 할 수 없다 고 생각한다.그러면 전형 적 인 Hibernate 방법 으로 분야 모델 을 만 드 는 방법 을 살 펴 보 겠 습 니 다. (robbin 의 두 번 째 모델 참조)

public class Item {
  public Bid placeBid(User bidder, int bidAmount, Bid currentMaxBid) {
     if (currentMaxBid != null && bidAmount <= currentMaxBid.getAmount()) {
        throw new BizException("Bid too low.");
     }
     Bid newBid = new Bid(this, bidder, bidAmount);
     bids.add(newBid);
     return newBid;
  }
}

그 오래된 게시 물 (나 는 알 고 있다, n 년 전) 에서 칠 채 늑대 가 문 제 를 제기 했다. 바로:
인용 하 다.
세 번 째 클래스 DomainLogic, 즉 복잡 한 조회 에 의존 해 야 하 는 Logic
그렇다면 이런 논리 가 필요 한 것 은 무엇 입 니까?먼 곳 은 하늘가 에 있 고, 가 까 운 곳 은 눈앞 에 있다.current MaxBid 어디서 났 어 요?다 오 에서 꺼 낸 거 잖 아.내 Item 은 자신의 bids 를 포함 하고 있 는데, 그것 은 뜻밖에도 max Bid 가 무엇 인지 알 방법 이 없고, 밖에서 매개 변수 로 들 어 와 야 한다.이것 은 불합리한 것 이지 만 부득이 한 것 이다.Hibernate 의 고전적 인 해결 방안 은 이러한 조회 논 리 를 Domain 사용자 의 편 에 놓 고 DAO 를 호출 해 야 한 다 는 것 을 제약한다.하면, 만약, 만약...http://www.iteye.com/topic/191261) 내 가 말 한 RichSet 는 쉽게 해결 할 수 있다.

public class Item {
  private RichSet bids = new DefaultRichSet();
  public Bid placeBid(User bidder, int bidAmount) {
     Bid currentMaxBid = bids.max("amount");
     if (currentMaxBid != null && bidAmount <= currentMaxBid.getAmount()) {
        throw new BizException("Bid too low.");
     }
     Bid newBid = new Bid(this, bidder, bidAmount);
     bids.add(newBid);
     return newBid;
  }
}

max 가 부족 한 상황 에서 의 실현 은 목록 을 옮 겨 다 니 는 것 입 니 다.Hibernate 가 강화 되면 서 SQL 조회 가 되 었 습 니 다.bids. add 와 같은 결 성 된 상황 은 목록 작업 이 고, Hibernate 가 저장 할 때 SQL 의 INSERT 가 됩 니 다.
제 관점 은 이른바 대량 조작 이 Domain Logic 에 속 하지 않 는 것 은 Hibernate 로 인 한 제한 이라는 것 입 니 다.실제 도 메 인 에는 리 포 지 토리 라 는 대상 이 있어 야 한다.그것 은 List 를 봉 했다.

public class ItemRepository {
  private RichList items
  public ItemRepository(RichList items) {
    this.items = items;
  }
}

분야 의 대상 이 되 는 아 이 템 Repository 는 아 이 템 이 어디서 왔 는 지 에 관심 이 없다.이 items 는 domain 의 모든 item 이 라 고 생각 합 니 다.따라서 addItem 의 item 은 이름 이 중복 되 지 않 는 검사 없 이 자 연 스 럽 게 Item Repository 에 놓 을 수 있 습 니 다.

public class ItemRepository {
  public void addItem(String name) {
    if (items.find("name").eq(name).size() > 0) {
       throw new BizException("name duplicated");
    }
    Item item = new Item(name);
    items.add(item);
    return item;
  }
}

도 메 인 에 서 는 모든 아 이 템 목록 이 아 이 템 Repository 로 포장 되 어야 합 니 다.아 이 템 의 이름 유일 성 을 보장 합 니 다.