0
내가 작업하고있는 프로젝트에서 등이 포함 된 DebtCollectionCase 개체가 있습니다 ... 발생하는 문제는 항상 증가하는 쿼리의 수가 증가하고 계속 증가하는 것입니다. 그리고 나는 그 쿼리들에서 많은 계산을 반복했다. 예를 들어, 계산은 UnpaidAmount 또는 Interest이됩니다. 그것은 이미 엉망이며 시간이 갈수록 악화 될 것입니다.쿼리의 비즈니스 로직 복제
해결책은 Domain Objects에서 모든 장소에서 재사용 할 수있는 함수로 계산하는 것이지만, 메모리에서 전체 집계를 가져와야하므로 DebtCollectionCase, Invoices, Payments, CreditNotes을 가져와야하고 함수를 호출하여 계산을 수행하십시오. 하나의 레코드에 대해서는 괜찮을 것입니다.하지만 그 중 하나 인 Invoices 및 Payments를 사용하여 DebtCollection 케이스를 찾아야하는 경우에는 무엇이 필요할 지요. 그것은 가져온 데이터의 양이 많아서 퍼포먼스에 영향을 미칠 수 있습니다.
따라서 재사용 및 유지 보수에 유리하며 쿼리에 Bussines 논리를 추가하는 것이 더 나은 성능을 의미하지만 유지 보수 및 DRY를 위반하는 것은 더 어려워지는 문제입니다. 누구든지 내가 사용해야하는 조언이 있습니까?
아마도 도메인 디자인이 좋지 않을 수 있습니다. 더 구체적으로, 그것은'DebtCollectionCase' "aggregate"가 확실히 너무 크고 비즈니스 불변량을 반영하지 않는 것 같습니다. 그래서, 나는 당신의 모델을 다시 생각하기 시작할 것입니다. 여전히 괜찮다고 생각하거나 변경할 수 없다면 데이터베이스 효율적인 쿼리 (저장소 패턴이 괜찮을 수도 있음)가 지원하는 특수한 "프로젝션"읽기 전용 모델을 사용할 것입니다. 너의 문제를 이해하면 알려줘. –
세 번째 옵션은 결과 계산을 속성에 캐시하고이를 DB에 저장하는 것입니다. 복잡한 요소로 인해 상태의 특정 부분이 복잡해질 때 (반응 형 프로그래밍 기술이 도움이 될 수 있음) 속성을 다시 계산해야하지만 쿼리를 유지하면서 비즈니스 논리를 도메인에 유지할 수 있습니다 간단하고 효율적입니다. – plalx
해결책을 찾았습니다. DelegateDecompiler라고합니다. 그것은 엔티티 매핑되지 않은 속성과 기능을 linq Select 및 Where 문에서 사용할 수 있습니다. 즉, 재사용 가능하고 SQL로 변환되므로 메모리에서 엔티티를 가져올 필요가 없습니다. 누군가가 https://github.com/hazzik/DelegateDecompiler를 필요로한다면 링크가 있습니다. – Aleksa