비즈니스 계층에서의 캐싱과 데이터 계층에서의 캐싱

나는 항상 DAL에서 캐싱이 수행 된 프로젝트에서 일해 왔습니다. 기본적으로 데이터베이스를 호출하려고 할 때 데이터가 이미 캐시에 있는지 확인하고 있으면 캐시를 호출하지 않습니다. 대신 해당 데이터를 반환합니다.

최근에 비즈니스 계층에서 캐싱에 대해 읽었으므로 기본적으로 전체 비즈니스 개체를 캐싱합니다. 내가 곧바로 볼 수있는 한 가지 장점은 훨씬 더 나은 응답 시간입니다.

언제 다른 것을 선호합니까? 비즈니스 계층에서의 캐싱은 일반적인 관행입니까?

c# design design-patterns caching

— 엠마
소스

리포지토리 또는 DAL 계층에 대한 추가 호출의 명확성을 피하는 것보다 비즈니스 계층의 캐싱을 선호 할 수 있도록 응용 프로그램의 성능이 매우 중요합니까?

— JDT

답글을 읽은 후에는 DAL에서 캐싱을 고수 할 것이라고 생각합니다. 건배.

— 엠마

비즈니스 계층 위의 캐싱을 고려하고 확장에 대해서도 고려해야합니다.

— AK_

답변:

이것은 아마도 명확한 대답을하기에는 너무 광범위 할 것입니다. 개인적으로 저는 데이터 액세스 계층이 캐싱하기에 더 좋은 곳이라고 생각합니다. 단순히 매우 단순해야하기 때문입니다. 레코드가 들어오고 나갑니다.

비즈니스 계층이 구현 높은 복잡성 많은 추가 규칙을, 그렇지 않은 경우의 더 나은 그래서 또한 그 것 - 다중 객체의 일관성 같은 클래스에서 문제 (또는 같은 방법)에 추가하여 개체 별 가용성 문제를 관리해야 SRP를 명백히 위반하는 행위

(물론 캐싱과 구성을 동시에 수행하려고 할 때 서비스 클래스가 관리하기 어려운 복잡성으로 성장한 후에야 통찰력에 도달했습니다. 경험보다 더 나은 교사는 없지만 가격은 가파 릅니다.)

— 킬리안 포스
소스

캐싱이 복잡한 이유는 무엇입니까? AOP와 몇 가지 주석으로 수행 할 수 있습니다. 여전히 SRP를 위반합니까? 왜 DAL에서 완료되지 않았습니까? 또한 IMHE 나는 서비스 클래스가 "너무 복잡해"캐시되는 것을 본 적이 없다. 복잡성과 무관하게, 서비스는 블랙 박스로 보여지고 결과는 캐시 될 수 있습니다

— user1075613

데이터 액세스 및 지속성 / 스토리지 계층은 캐싱을위한 자연스러운 장소입니다. 그들은 I / O를하고있어서 캐싱을 삽입하기에 편리하고 쉬운 곳입니다. 나는 거의 모든 DAL 또는 퍼시스턴스 레이어가 성숙함에 따라 캐싱 기능을 갖게 될 것이라고 감히 주장한다.

문제는 의도 입니다. DAL 및 지속성 계층은 레코드, 테이블, 행 및 블록과 같이 상대적으로 낮은 수준의 구성을 처리합니다. "비즈니스"또는 응용 프로그램 계층 개체를 보지 못하거나 더 높은 수준에서 어떻게 사용되는지에 대한 통찰력이 있습니다. 그들이 읽거나 쓰는 소수의 행이나 12 개의 블록을 볼 때 그것들이 나타내는 지 확실하지 않습니다. "현재 분석중인 Jones 계정"은 "앱이 한 번만 필요로하고 다시 참조하지 않는 일부 기본 과세율 참조 데이터"와 크게 다르지 않습니다. 이 계층에서 데이터는 데이터가 데이터입니다.

DAL / 지속성 계층에서 캐싱하면 "콜드"세금 참조 데이터가 저장되어 무의식적으로 12.2MB의 캐시를 차지하고 실제로 1 분 동안 집중적으로 사용될 계정 정보를 대체합니다. 최고의 캐시 관리자조차도 더 높은 수준의 데이터 구조 및 연결에 대한 정보를 다루지 않으며 어떤 작업이 곧 이루어질 지에 대한 통찰력이 거의 없으므로 추측 알고리즘으로 되돌아갑니다 .

반면에 응용 프로그램 또는 비즈니스 계층 캐싱은 그다지 깔끔하지 않습니다. 다른 비즈니스 로직 중간에 캐시 관리 작업 또는 힌트를 삽입해야하므로 비즈니스 코드가 더 복잡해집니다. 그러나 매크로 레벨 데이터가 어떻게 구성되고 어떤 작업이 진행 될지에 대한 지식이 많으면 최적 ( "취득자"또는 "Bélády Min") 캐싱 효율성을 근사화 할 수있는 훨씬 좋은 기회가 있습니다.

캐시 관리 책임을 비즈니스 / 애플리케이션 코드에 삽입하는 것이 합리적 일지 여부는 판단 요구이며 애플리케이션에 따라 다릅니다. 많은 경우에 DAL / 지속성 계층이 "완벽하게 옳은"것을 얻지 못한다는 것이 알려져 있지만, 절충안은 그들이 아주 좋은 일을 할 수 있다는 것입니다. 낮은 수준의 잡기는 비즈니스 / 앱 코드의 복잡성을 증가시키지 않습니다.

복잡성이 낮을수록 정확성과 신뢰성이 향상되고 출시 기간이 단축됩니다. 이는 완벽한 캐싱이 적지 만 품질이 더 좋고시기 적절한 비즈니스 코드 인 경우가 많은 훌륭한 트레이드 오프로 간주되는 경우가 많습니다.

— 조나단 유니스
소스

답장을 보내 주셔서 감사합니다. 귀하와 다른 사람의 답변을 읽은 후에는 비즈니스 계층에 캐시 할 필요가 없습니다. 제품의 전체적인 복잡성을 증가시킬뿐입니다.

— 엠마

"계층"모델의 한 가지 문제점은 효율적인 캐싱 메커니즘이 종종 단일 계층에서는 사용할 수없는 정보를 사용해야한다는 것입니다. 그러나 비즈니스 계층이 전체 "계획"에 대해 "힌트"를 데이터 계층에 전달하는 것에 대해 어떻게 생각하십니까? 데이터 계층은 처음에 이러한 힌트를 대부분 무시할 수 있지만 병목 현상이 발견되면 특정 힌트가 제공 될 때 비즈니스 고유의 방식으로 캐싱 전략을 변경하는 일부 논리가 추가 될 수 있습니다.

— supercat

훌륭한 포인트, @supercat. 나는 힌트 / pragma 전략을 언급하려고했지만 그 대답은 이미 오래되었습니다. 그러나 당신은 정확히 맞습니다. 비즈니스 계층은 캐시 우선 순위를 정하는 방법 또는 "고정 대상"에 대한 하위 계층 힌트는 비즈니스 코드를 모두 수행하지 않고 자체 수준의 캐싱을 얻거나 자체 스토리지 관리에 너무 익숙해지지 않는 매우 일반적이고 유용한 방법입니다. 계층.

— Jonathan Eunice

@JonathanEunice : 힌트에 대한 좋은 점은 코드가 처음에 많은 작업을 수행 할 필요가 없다는 것입니다. 많은 시스템에는 성능을 좌우하는 몇 가지 명백한 병목 현상이 있지만 어느 시스템이 문제가 될만큼 나쁜지 예측하기가 어려울 수 있습니다. 몇 가지 중요한 지점에 소량의 추악한 캐싱 로직을 추가하는 것이 실제로 중요하지 않은 장소에 많은 캐싱 로직을 뿌리는 것보다 낫습니다.

— supercat

정확하게. 특히 지속성 / 액세스 계층에 이미 "꽤 좋은"저수준 캐싱이있는 경우. "정말 양호"에서 "정말 양호"로 이동하려면 우선 순위 정보를 조금만 추가하면됩니다.

— Jonathan Eunice

DAL에서의 캐싱은 간단하고 간단합니다.

DAL은 중앙 데이터 액세스 계층이므로 모든 데이터 액세스를 클래스를 통해 제어 할 수 있습니다. 해당 계층에서 읽기와 지속이 모두 발생하므로 변경 사항이 발생할 때 캐시 항목을 지우거나 업데이트하는 것도 쉽습니다.

비즈니스 캐싱은 유연합니다

비즈니스 캐싱은 개발자에게 객체의 구체적인 사용이 캐싱의 이점을 얻을 수 있는지 여부를 결정할 수있는 유연성을 제공합니다. 응용 프로그램 백엔드 서비스 또는 자동화 된 프로세스의 구조에 따라 다른 부분에 캐시 된 데이터가 변경 될 수 있습니다. 비즈니스 캐싱을 통해 개발자는 특정 비즈니스 개체가 부실한 데이터를 가지고 성능을 얻을 수 있는지 또는 성능을 희생하여 비즈니스 개체의 최신 상태를 유지할 수 있는지 확인할 수 있습니다.

— JDT
소스