Repository에 대한 체크 리스트
위의 체크 리스트는 Repository를 구현할 때 고려되는 사항을 뽑은 것입니다.
들어가기에 앞서 다시 한번 마틴파울러의 Repository의 정의를 다시 살펴 보면,
리파지터리란 도메인 객체에 접근하기 위해 컬렉션과 같은 인터페이스를 사용하는 , 데이터 매핑 레이어와 도메인 사이의 중재자 이다.
Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
더 자세한 정의 및 Repository pattern에 대해서는 이전 포스트 http://smack.kr/300 에서 다루고 있습니다.
위의 정의로 보아 리파지터리의 조건은
도메인이 클라이언트가 되고, 데이터 매핑 레이어에 대해서 컬렉션 형태의 인터페이스와, Persistance Ignorance를 지원한다.
1. 어떤 entity에서도 동작하는 제네릭 리파지터리를 사용 하느냐, 아니면 각각의 entity에 특화된 리파지터리를 사용할 것인가?
(Do you use a Generic Repository that can work for any entity, or a Specialised one for each entity? )
각각의 특화된 리파지터리를 사용하는 것은 Jimmy Nilsson의 Applying Domain-Driven Design and Patterns: With Examples in C# and .NET의 예를 들 수 있다.
특화된 리파지터리는
class Product
class Order
interface IRepository
class ProductRepository : IRepository
class OrderRepository: IRepository
형태를 가지며,
interface IRepsitory는 기본 CRUD만을 정의 하며, 상속 받은 ProductRepository , OrderRepository가 ProductRepository.GetProductByKey(int itemKey)와 같은 확장된 메소드를 구현 할 수 있다.
사실 IRepository를 상속 받지 않아도 된다. 특화된 Repository는 거의 LSP를 지킬 수가 없고, 이는
Product->IRepository = new ProductRepository의 형태를 사용 할 수 없기 때문이다. 하지만, SRP를 구현하기 에는 명확하다.
제네릭 리파지터리는 interface IRepsotory<T> 와 같은 형태를 가지게 되는데 , class Repository<T> : IRepostory<T>로 구성되며,
Product -> IRepository = new Repository<Product>();
Order -> IRepository = new Repository<Order>();
와 같이 구상 클래스가 아닌 , 인터페이스를 가지고 프로그래밍을 할 수 있다.
또한 class InMemoryRepository<T> : IRepository<T> 형태의 In-Memory Repository를 추가 할 수 있으며, 이는
Product->IRepsitory = new InMemoryRepository<Product>();
Order -> IRepository = new InMemoryRepository<Order>();
와 같은 형태로 Persistence-Ignorance의 개념을 명확하게 구현 할 수 있다.
하지만, 잘 정의된 제네릭 리파지터를 구현하는 것은 쉬운 일이 아니다.
2. 쿼리는 어디에 존재 해야 하나?(Where are queries constructed?)
쿼리는 일반적으로 Repository 내부에 정의 되는데, 특화된 리파지터리와 제네릭 리파지터리는 약간 다른 형태를 띄게 된다.
3.데이타 저장소로 부터 데이터를 어떻게 꺼내고 집어 넣나? (How do repositories move data in and out of the data store? )
4. 어떤 쿼리 언어를 사용하나? What query language are you using (HQL, LINQ, SQL etc)?
5. 트랜잭션은 어디에서 핸들링 해야 하나? (Where are transactions handled? )
6. 엔터티가 리파지터리를 알아야 하나?( Do entities know about the Repositories?)
7. 도메인 서비스는 어떤 일을 하는가? ( What do your domain services do?)
8. 어플리케이션 서비스는 어떤 일을 하는가? (What do your application services do?)
9. 리파지터리에 대한 테스트는 어떻게 하는가? ( How do you test your repositories?)
10. ASPX 페이지는 도메인과 이야기 하는가? 아니면 항상 어플리케이션 서비스를 통하는가? (Do ASPX pages talk to the domain too, or do they always go through application services?)
위의 질문에 대한 Collin Jack의 아키텍처는
DDD Repositories in the Wild: Colin Jack
http://www.tobinharris.com/past/2008/8/22/ddd-repositories-in-the-wild/
에서 확인 할 수 있습니다.
MSDN Magazine 2009년 2월호 에서는 DDD에 대해서 다루고 있으며
DDD(Domain Driven Design) 소개
David Laribee : http://msdn.microsoft.com/ko-kr/magazine/dd419654.aspx
위의 링크는 도메인 드리븐에 대한 설명과 참조 링크들을 제공하고 있습니다.
'아키텍처' 카테고리의 다른 글
| Microsoft Application Architecture Guide, 2nd Edition V2 (0) | 2010/03/23 |
|---|---|
| 실수를 허락하라! (0) | 2009/10/06 |
| DDD Repositories를 더 생각해 보자 (DDD Repositories further more) (1) | 2009/03/24 |
| 도메인로직(비지니스로직) - 트랜잭션 스크립트(Transaction Script) (0) | 2009/03/09 |
| Repository Pattern (0) | 2009/02/10 |
| Application Architecture Guide 2.0 - Final Release (1) | 2008/12/30 |






