비즈니스 개체 간 순환 참조가 (계층 구조에서) 공통적입니까?

Question

Linq-to-Sql 클래스는 부모에게 자식 컬렉션에 대한 참조와 부모에 대한 참조 (단일 또는 컬렉션)를 모두 제공합니다. 이렇게하면의 두 방향으로 "드릴"을 사용할 수 있으며 매우 편리해 보입니다.

수동으로 작성된 비즈니스 오브젝트 (POCO 또는 기타)에도 사용하기 적합한 디자인입니까? 경우에; 찬성/반대 의견, 또는 이것이 권장 될 구체적인 상황은 무엇인가?

---

EDIT1 :

나는 논리 중심의 행동에 대해 주로 생각하고 있어요; 사용자 상호 작용이 아니라 금융 거래, 게임 소프트웨어 등을 다루는 프로그램과 같은 의미입니다. 하위 엔티티를 다루고 부모의 매개 변수가 필요한 경우 어떻게할까요? 아주 편리하지만 어쩌면 문제가되는 코딩 관행의 다른 부분 일 수도 있고 내가 이걸 필요로한다고 느낄 수도 있습니다 ..

Answer 1

예, 양방향 참조는 일반적이며 유용합니다. 그것들은 객체 지향 아키텍처에서 완벽하게 유효합니다. 이점은 도메인 객체를 모델링하고 객체를 효율적으로 트래버스하는 데 도움이된다는 점을 지적하는 것입니다. 부정적인 측면에서 정보가 더 많은 경로를 따라 가면서 코드를 이해하기가 더 어려워 질 수 있습니다.

그러나 RDMS 신을 닦으려는 시도에 너무 많은 걱정을하지 않아도됩니다. 기본 데이터 저장소에 문제가 발생할 가능성은 거의 없으며, 하루가 끝날 때, 당신의 매핑 기술은 중간 정도 괜찮은 매핑 전략을 제시 할 것입니다. 그렇지 않으면 그것을 대체해야합니다.

Answer 2

정말로이 답변을 찾고 있는지 확실하지 않지만 여기에 2 센트입니다.

순환 참조는 모든 비용을 들이지 않아도 피해야하는 끔찍한 데이터베이스 디자인입니다.

작업 순서를 미리 결정할 수없고 레코드에 포함 된 데이터에 크게 의존하기 때문에 레코드 배치의 체계적인 삽입 및 삭제가 거의 불가능합니다.

이의 예는 무언가 같이 될 것이다 : 데이터베이스를 처리 할 때 당신은 말 그대로 여기 캐치 22 (또는 병아리 먼저 냐 달걀이 먼저 냐의 문제) 상황이

class Company 
{ 
    Person ContactPerson {get;set;} 
} 

class Person 
{ 
    Company Company {get;set;} 
} 

.

코드에서 다루는 것은별로 문제가되지 않습니다.

Answer 3

부모 개체에서 자식 컬렉션을 참조하는 것은 가능한 경우 일반적으로 피해야하는 항목입니다. 컬렉션이 항상 작을 가능성이 있다면, 아마 그 컬렉션을 벗어날 수 있습니다. 그러나 컬렉션이 크다면 성능 문제를 피할 필요가 있습니다.

부모에서 자녀에게 참조를 추가하기 전에 기능적 요구 사항을 고려해야합니다. 일반적으로 부모의 ID를 기반으로 어린이를 조회 할 수 있습니다. 또한 컬렉션 크기가 큰 많은 응용 프로그램에서 페이지 전체를 사용하여 전체 컬렉션의 일부만 검색 할 수 있습니다.

Answer 4

메모리 엔티티의 경우 양방향 탐색이 매우 편리 할 수 ​​있습니다. 특히, 지속 때 그러나,이 문제를 제기 :

• 저장을 RDBMS와에 - Leppie에 따라. 일대 다 관계의 경우 상위 FK는 하위 레코드에 저장됩니다. 일대일 관계의 경우 관계를 다른 FK로 저장하지만 단 하나의 방법으로 만 저장하십시오.
• 전선을 통한 일련 번호 지정은 큰 두통을 일으킬 수 있습니다. 일반적으로 일대 다 관계에서 자식은 부모 아래에 중첩되어 있습니다 (관계는 계층 구조에 의해 보존됩니다). 그러나 자식 엔터티에 부모에 대한 참조가있는 경우 부모 개체 참조는 일반적으로 재귀 (사이클)로 인해 으로 serializable로 표시되지 않습니다. (PreserveObjectReferences하지만 WCF 3.5+에서는 이제 (IsReference = true)를 사용하여이 문제를 해결했습니다.

어느 쪽이든 저장/직렬화에서 그래프를 다시 수화 한 후 양방향 관계 참조를 '수정'해야합니다. (Linq2Sql에 의해 생성 된 코드를 살펴보십시오)