나는 내 2 센트를 줄 수 있는데, 내 대답이 조금 길다면 유감스럽게 생각한다.
이 종류의 계단식 충돌이있는 경우 계단식 접근 방식이나 도메인 모델이 잘 정의되지 않았기 때문일 수 있습니다. 캐스케이드 전략을 전체 그래프 또는 관련없는 요소 집합으로 일반화하는 데주의해야합니다.
캐스케이드 전략은 강하게 결합 된 데이터 집합과 Java 세계의 클래스 및 해당 (개인) 내부 클래스와 같은 유형의 데이터에만 사용해야한다고 조언합니다. 상위 클래스와 하위 클래스 간의 관계도 독점적이어야합니다 (UML에서는 비공유 연합이라고 함).
물론 우리는 다르게 할 수 있지만 (우리 모두가 게으름을 피울 수 있습니다.) 결국 단일 지속성 흐름 (또는 지속성 구성)과 비즈니스 흐름을 연결하는 웹을 만들 수 있습니다. 예외를 많이 관리하고 이전에 저장 한 계단식 전략 (저장, 업데이트, 삭제)을 중심으로 많은 구성 논리를 수행해야합니다.
극단적 인 접근법은 하나의 큰 루트 객체 만 저장하려는 경우가있을 수 있습니다. 왜 안돼? 나머지는 계단식으로 지속되어야한다. 그러나 실제로 이것은 시스템의 유지 보수성을 심각하게 제한 할 수 있습니다. 또한,로드, 저장 및 병합 할 때 메모리에서 큰 그래프의 상태를 관리해야 할 수도 있습니다.
웹 응용 프로그램 또는 클라이언트 - 서버 응용 프로그램을 수행하는 경우 웹 워크 플로는 루트 요소의 모든 것을 저장하지 않고도 요청할 때마다 제한된 개체 집합을 저장할 수 있어야합니다. 나는 당신의 질문에 직접 응답하지 않는다는 것을 압니다. 따라서 예로 돌아가십시오.
P는 은행이고 C1과 C2는 두 개의 클라이언트이고 A는 제품입니다.
나는 2 개의 쉬운 대답을 가지고있다 : 1) 각 레이어는 계단식없이 별도로 저장할 수있다. 그러나 동일한 트랜잭션 내에서, 그리고 동일한 DAO에서 또는 원하는 경우에 수행 할 수 있습니다.
2) P와 C는 케스케이드 될 수 있습니다. 그러나 A는 다른 워크 플로우에 저장되어야합니다.
그는 "도메인 기반 분석"에 대해 이야기하는 곳은 피터 코드의 장을 생각 나게 : http://www.petercoad.com/download/bookpdfs/jmcuch01.pdf
이 장에서는 그래프에서 다른 개체가 다른 원형에서 분리 될 수있는 방법에 대해 설명합니다. 지속성 워크 플로는 트랜잭션 데이터와 설명 또는 "사물"간에 동일하지 않아야합니다. 이렇게하면 계단식 전략을보다 효과적으로 구현하는 데 도움이됩니다.
The four archetypes of Peter Coad are:
- Is it a moment or interval?
- Is it a role played?
- Is it a catalog-entry-like description?
- Otherwise, it's a party, place, or thing.
도움이되기를 바랍니다.
