2012-01-20 4 views

답변

8

개인적으로 저는 컨트롤러 또는 일반적으로 프리젠 테이션 레이어에 리포지토리를 보는 것을 좋아하지 않습니다. 그러나 나는 그것을 여러 번 보았고 DDD의 맥락에서 잘못된 점은 아무것도 없습니다.

답변은 프로젝트의 규모에 달려 있다고 생각합니다. 서비스 레이어는보다 복잡한 프로젝트에서 더 자주 발견됩니다. 예를 들어 단순한 MVC 웹 사이트는 리포지토리를 직접 사용합니다.

+1

"컨트롤러에 리포지토리가 보이기 싫어"=> 컨트롤러와 리포지토리간에 추가해야하는 이유와 중간 계층을 자세히 설명 할 수 있습니까? – guillaume31

+1

컨트롤러는 매우 빨리 부풀어 오르는 경향이 있습니다. 그 이유 중 하나는 devs가 자신의 컨트롤러에 비즈니스 논리를 고수하기 때문입니다. 비즈니스 로직은 주로 도메인 계층에만 존재해야하며 서비스 계층에서는 컨트롤러가 아니라 저장소에 있어야합니다. 귀하의 컨트롤러에서 (응용 프로그램) 서비스를 사용하면이를 피할 수 있습니다. 예를 들어 accountService.GetUserByEmail (email) 또는 catalogueService.GetProductViewModel을 호출 할 수 있습니다. 컨트롤러가 멋지게 유지되고 응용 프로그램 서비스가 다양한 리포지토리와 통신 할 수 있습니다. – autonomatt

+3

저장소에서 객체를 가져 왔다고해서 비즈니스 로직을 다루는 것은 아닙니다. 도메인 계층의 객체를 다른 계층에 사용하기위한 것입니다. 그리고 한 줄의 userRepository.GetUserByEmail (전자 메일)이 accountService.GetUserByEmail (전자 메일) 이상의 컨트롤러를 차지하는 것을 볼 수 없습니다. – guillaume31

2

도메인 개체를 가져 오기 위해 저장소를 직접 사용할 수 있습니까?

확실히 할 수 있습니다. 정확하게 저장소의 목표입니다. 나는 당신이 그렇지 않으면 SOA 나 웹 서비스 기반 아키텍처의 특정 상황을 제외하고 어떤 종류의 서비스를 사용하는지 궁금합니다.

+0

서비스를 우회하여 리포지토리 (예 : MVC 컨트롤러)에서 직접 도메인 엔터티를 가져올 수있는 경우 내 의도 된 질문이있었습니다. – jgauffin

+0

글쎄, 맞았고 대답은 '예'입니다. 평범하고 일반적인 당신이 원래 DDD 책과 운동을 보면 사람들이 지금 두려워하는 것 같습니다 ... – guillaume31

+0

나는 두려워하지 않습니다. 방금 모범 사례가 무엇인지 알고 싶었습니다. 이 책은 9 년 전에 발표되었고 그 이후로 한두 가지 일이 일어 났을 것입니다. – jgauffin

0

DDD 원칙을 사용하여 구조화 된 첫 번째 프로젝트를 완료 한 후 : D, 응용 프로그램 계층에서 사용할 수있는 도메인 서비스와 리포지토리를 모두 보유하는 것이 유용하다는 것을 발견했습니다.

키 포인트 : 응용 프로그램 계층은 해당 아키텍처를 사용하는 경우 웹 서비스의 WCF 서비스 또는 코드 일 수 있습니다. 그것은 모두 구현에 따라 다릅니다. 구현에 적합하다면 응용 프로그램 계층이 프레젠테이션 계층과 같을 수 있으므로 응용 프로그램 계층 코드가 contollers 또는 Web forms 코드 뒤에 포함될 수 있습니다.

리포지토리는 메모리 내 컬렉션과 동일하게 작동합니다. 응용 프로그램 계층에 코드는 이전 컬렉션을 사용하는 것처럼 보입니다.

도메인 서비스는 결코 업데이트되지 않고 처리 될 수는 있지만 직접 업데이트되지 않는 정보에 대한 프로세서 또는 접근 자처럼 기능합니다. 응용 프로그램 계층에서 코드는 이전 웹 서비스를 사용하는 것처럼 보입니다. 말했다되고 그건

, 나는 몇 가지 예제와 함께 자세한 내용을 설명합니다 :

내 저장소 실제로 내가 만든 구현 객체에 입력 일반적인 컬렉션을 상속

저장소는 데이터베이스 키와 사업을 캡슐화 함께 모델. 이 방법을 사용하여, 나는 내 인터페이스 등

BusinessObject this[int index]; 

에 인덱서를 정의 할 수 있습니다 나는 데이터 키를 조회 할 기본 모음의 인덱스와 세터를 기반으로 비즈니스 오브젝트를 반환하는 게터를 가질 수 있습니다 기본 컬렉션에서 가져 와서 개체를 데이터베이스에 저장하십시오. 이 내가 개별적으로 편집하지 않을거야 엔티티와 값 객체의 목록을 검색하는 서비스를 사용하고

, 내 경우입니다

IBusinessObjectRepository repository = new SqlBusinessObjectRepository(sqlString); 
BusinessObject obj = repository[0]; //Get first object in the list. 
//Make some changes to the business object by setting properties or calling methods to process business logic. 
repository[0] = obj; //Save the object back to the database. 

서비스, 예를 들어, 응용 프로그램 코드는 매우 간단합니다 집계 루트에서 메소드를 호출 할 때 사용 가능한 선택 사항 또는 값으로 만 사용됩니다.일반적으로이 정보는 웹 서버에 저장됩니다. 이것은 도메인 서비스에 대한 유일한 용도는 아니며 제 예제입니다. 응용 프로그램 계층 코드는 여전히 비교적 간단합니다.

IBusinessService service = new ImplBusinessService(implementationArgs); 
List<BusinessObject> objsToCache = service.GetBusinessObjects(); 
//cache the objects on the web server. 

결론적으로 DDD 원칙을 이해하면 응용 프로그램 계층은 서비스 또는 저장소에서 비즈니스 개체에 액세스 할 수 있어야합니다. 두 모델 사이의 선택은 도메인 모델 내에서 가장 잘 맞는 것으로 결정됩니다.

관련 문제