2010-07-07 2 views
4

내 응용 프로그램은 도메인 개체의 큰 트리를 사용하며 이러한 개체의 대부분에 대해 몇 가지 기본 정보 (updatedby, 수정 된 시간 등)를 유지하고 싶습니다. 내 응용 프로그램에 이미 이러한 속성 & 열을 추가했습니다.도메인 개체에 대한 기본 감사 데이터를 저장하는 쉬운 방법은 무엇입니까?

필자는 퍼시스턴스 계층이이를 투명하게 처리해야한다는 생각이들 때 모든 다양한 생성자에서 이러한 값의 설정을 코딩하려고했습니다.

하지만 어떻게?

확실히 내 DAO 내에서이 작업을 수행 할 수 있지만 캐스케이드 저장을 통해 유지되는 개체를 처리하는 방법은 무엇입니까? 거기에 persist() 메소드를 가로채는 방법이 있습니까?

이 기능을 구현하는 좋은 방법은 무엇입니까?

답변

5

감사의 목적으로 JPA를 사용하려는 경우 PrePersist 및 PreUpdate 콜백 주석에 의존 할 수 있습니다. JPA WikiBook has one such example. 이 경우 맵핑 된 수퍼 클래스를 갖는 것이 크게 도움이됩니다. 그렇지 않으면 "사용자"공간 코드를 통해 계속 수행 할 것입니다.

이렇게하는 또 다른 방법은 테이블에서 트리거 (ahem)를 사용하는 것입니다. 이것은 성능에 영향을 미칩니다. Openbravo ERP project은 감사 추적을 생성하는 데이 방법을 사용하는 것 같습니다.

업데이트 : 감사 기능을 도메인 모델의 수퍼 클래스 이외의 다른 클래스로 구분하는 것이 좋습니다. JPA 이벤트 리스너가 동일한 목표를 달성하는 데 도움을줍니다. 좋은 예가 현재 here입니다.

+0

순수 JPA의 장점. PrePersist 및 PreUpdate 관련 팁 및 링크를 제공해 주셔서 감사합니다. 모든 감사 정보를 단일 테이블에 저장한다는 생각에서 잠재적 인 성능 병목 현상이 발생합니다. – HDave

+1

흠, 흥미로운 질문입니다. 대답은 당신이 단일 테이블에 저장하고있는 것과 얼마나 자주 쿼리되고 있는지에 달려 있습니다. 사용자가 일반적인 작업 과정에서 감사 정보를 상대적으로 많이 조회하고 조회 할 것으로 예상하는 경우 각 항목을 개별적으로 감사하는 것이 좋습니다. 그러나 감사 테이블이 SELECT 전용 테이블이 될 예정이라면 성능 측면에서 걱정할 INSERT 만 있으므로 덜 해치울 수 있습니다. 생산 계획 수립을 예상하기 위해서는 어느 정도의 용량 계획이 필요하다고 생각합니다. –

+0

필자의 경우, 대부분의 경우이 정보에 대한 많은 업데이트와 쿼리가있을 것이므로 엔티티와 동일한 레코드에 계속 저장해 나갈 것입니다. 그러나, 나는이 정보를 외부화하는 것이 큰 도움이 될 몇 곳을 가지고있다. – HDave

6
+0

와우 - 엔버는 굉장합니다. 나는 전에 그것에 대해 어떻게 알지 못했습니까? 그것을 심각하게 고려할 것입니다. – HDave

관련 문제