Repository Pattern

정의

데이터 조희 로직 이 레파지터리에 들어가려는 현상.

 

문맥:

많은 어플리케이션에서 비즈니스 로직은 데이터베이스, 쉐어포인트, 웹서비스와 같은 데이터저장소의 데이터에 접근합니다. 직접접근은 다음과 같은 부작용을 초래할 수 있습니다.

중복된 코드

프로그래밍 에러가 발생할 높은 잠재성

비즈니스 데이터에 대한 오타

캐싱과 같은 데이터-관계 정책 중심화하기 어려움

외부 의존으로 부터 비즈니스 로직을 분리하기 어려움에 따른 테스트 불가능성

 

출처: http://vandbt.tistory.com/27 [소프트웨어 디자인- Design Software by vandbt]

 

목표

복잡한 비즈니스 로직을 단순화 시키기 위해 도메인 모델을 적용하기를 원한다.

 

출처: http://vandbt.tistory.com/27 [소프트웨어 디자인- Design Software by vandbt]

 

 

고려사항:

리파지터리 패턴은 코드의 추상화 정도를 증가시킵니다.

이는 이 패턴에 익숙하지 않은 개발자가 코드를 이해하는데 있어 더욱 어렵게 만들 수 있습니다. 이 패턴을 구현하는 것이 수많은 양의 코드 중복을 감소시키지만  관리해야 하는 클래스 수를 증가 시킵니다. 

리파지터리는 서비스와 리스트에 접근하는 코드를 분리하는데 도움을 줍니다.

고립은 독립적인 서비스처럼 다루기 쉽게 만들어 줍니다. 하지만 전형적으로 리파지터리 그 자체를 테스트하는 것은 매우 어렵습니다. 

 

멀티 스레드 환경에서 캐싱 데이터를 사용할 때 캐쉬 오브젝트에 대한 동기화도 고려해야 합니다. 종종 ASP.NET 캐쉬와 같은 일반적인 캐쉬는 스레드로 부터 안전하지만, 멀티 스레드 환경에서 작동 되는 오브젝트 그 차제에 대해 스레드로 부터 안전하도록 확인해야 합니다.

 

여러분이 고부하 시스템에서 데이터를 캐싱 한다면 성능 문제가 부가될 수 있습니다. 데이터소스에 대한 동기화 접근을 고려해 보세요. 이는 데이터에 대한 단일 요청만이 수행되도록 보장합니다. 

### 끝.

 

출처: http://vandbt.tistory.com/27 [소프트웨어 디자인- Design Software by vandbt]