저장소 패턴 - 캐싱

Question

저장소 패턴에서 캐싱을 구현해야하는 위치가 확실하지 않습니다.

서비스 로직이나 저장소에 구현해야합니까?

GUI -> BusinessLogic (서비스) -> DATAACCESS (저장소)

Answer 1

내가 저장소/데이터 액세스 레이어에서 처리 할 것입니다. 이유는 데이터를 가져올 위치, 즉 저장소의 작업에 따라 비즈니스 계층에 달려 있지 않기 때문입니다. 리포지토리는 데이터를 가져올 위치, 캐시 (너무 오래되지 않은 경우) 또는 데이터 액세스 논리의 상황에 따라 라이브 데이터 원본에서 결정합니다.

이것은 비즈니스 로직 문제 이상의 데이터 액세스 문제입니다.

Answer 2

SRP (Single Responsibility Principle) 및 우려 사항을 위반하는 캐싱 로직을 저장소에 직접 저장하지 않는 것이 좋습니다. SRP는 본질적으로 당신의 수업은 변할 하나의 이유 만 가져야한다고 말합니다. 데이터 액세스 및 캐싱 정책에 대한 우려를 같은 클래스에서 모으는 경우 이러한 변경이 필요한 경우 클래스를 터치해야합니다. 또한 DRY 원리를 위반하고있는 것을 발견하게 될 것입니다. 왜냐하면 많은 다른 저장소 방법들 사이에서 캐싱 로직이 쉽게 퍼져 나갈 수 있고, 변경이 필요한 경우 많은 방법을 변경해야합니다.

프록시 또는 전략 패턴을 사용하여 캐싱 로직을 별도의 유형 (예 : CachedRepository)에 적용한 다음 캐쉬가 비어있는 경우 필요에 따라 실제 db 중심 리포지토리를 사용하는 것이 더 좋습니다. 여기, 당신이 내 블로그에 발견 할 것이다이 사용하는 .NET/C 번호를 구현하는 방법을 보여 두 개의 기사를 작성했습니다

• http://ardalis.com/introducing-the-cachedrepository-pattern
• http://ardalis.com/building-a-cachedrepository-via-strategy-pattern

비디오를 선호하는 경우, 나는 여기, 인 Pluralsight에 프록시 디자인 패턴에 패턴을 설명합니다

• http://pluralsight.com/training/courses/TableOfContents?courseName=patterns-library