WCF 서비스를 올바른 방법으로 레이어링합니다

StackOverflow https://stackoverflow.com/questions/661530

문제

내 질문은 건축 적 특성에 더 가깝고 실제 구현에 덜 관여하는 것입니다.

WCF를 기반으로 API를 구축했지만 실제로 PL을 BL에서 분리하는 방법을 결정할 수는 없습니다. 서비스를 얇게 만들었으므로 다음과 같은 것만으로 최소한의 구현 만 보유했습니다.

public TagItemResponse TagItem(TagItemRequest request)
{
   return (new ItemTagRequestProcessor()).GetResponse(request);
}

물론 첫 번째 질문이 발생하는 것보다 요청 처리기가 어떤 계층에 속합니까? 나는 그들을 외관이라고 부르는 것이 잘못 될 것이라고 생각하지만 동시에 프레젠테이션과는 아무런 관련이 없습니다. 지금도, 나는 그럼에도 불구하고 그들이 PL에 속한다고 결정했습니다. 프로세서 메소드는 내 DTO (DataContracts)를 입력으로, 요청 메시지 (기본 클래스)를 검증하고 인증 (기본 클래스)을 입력하고 다음과 같은 단일 DTO 응답을 반환합니다.

protected override void Process(TagItemRequest request, TagItemResponse response, Host host)
{
    var profile = ProfileFacade.GetProfile(host, request.Profile);
    var item = ItemFacade.GetItemId(host, request.Item);
    var tags = new List<Tag>();

    foreach (var name in request.Tags)
    {
        var tag = TagFacade.GetTag(profile, name);
        ItemFacade.TagItem(item, tag);
        tags.Add(tag);
    }

    ItemFacade.UntagItem(item, tags);
}

이제 나는 나 자신에게 묻습니다. 왜 비즈니스 대상과 관련된 Facade 클래스 1 : 1이 필요합니까? 예를 들어, 나는 hostdao와 프로세서 사이의 레이어 역할을하는 hostfacade가 있습니다. 그러나 논리가 거의 없으며 DAO 호출을 처리합니다. 

public static Host GetHost(HostDTO dto)
{
   return HostDAO.GetHostByCredentials(dto.Username, dto.Password);
}

질문 : 프로세서와 외관을 통합 할 수도 있습니다.

나는 주제에 관한 많은 기사/책을 읽었지만 여전히 '올바른'방법에 정착 할 수는 없으며 문제에 직면 할 때마다 다른 접근 방식을 선택하는 경향이 있습니다. 올바른 접근 방식이 존재하는지 궁금합니다.

F.Ex를 찾았습니다. 서비스 구현 내에서 바로 DAO 클래스와 대화 한 Dofactory 예제. 대부분의 ServiceContract 방법이 일부 논리를 공유하므로 공유 기본 클래스와 함께 사용하기에 적합합니다.

또한 서비스 내에서 외관 만 호출되는 다른 예를 찾았지만 매우 세밀한 메시지에만 잘 작동하는 것 같습니다. 내 메시지는 서비스에 대한 통화 횟수를 최대한 줄이기 위해 '지방'과 합성물입니다. 내 추가 처리 계층은 내 실제 문제인 것 같습니다.

아마도 WCF 서비스를 올바르게 계층화하는 방법에 대한 단일 대답은 없지만, 내 본능을 준수하거나 저를 위해 주제에 대한 새로운 빛을 비추는 의견과 함께 여러분 중 일부가 있기를 바랍니다.

고맙습니다!

제프리

도움이 되었습니까?

해결책

먼저, PL에 의해 지속성 계층이 아니라 프리젠 테이션 계층을 의미한다고 가정합니다.

계층화 된 애플리케이션 설계를 구현할 때는 주요 질문은 항상 다음과 같습니다. 위의 계층의 구현에 영향을 미치지 않고 하위 계층의 구현을 교체 할 수 있습니까?

이것은 일반적으로 지속성 층으로 가장 잘 설명됩니다. 예를 들어 SQL Server 2008에서 MySQL로 전환하면 지속성 층이 변경됩니다 (물론). 그러나 비즈니스 계층의 변화도 필요합니까? 예를 들어, 비즈니스 계층은 sqlclient에 의해서만 던져지는 sqlexception 인스턴스를 포착합니까? 좋은 디자인에서 비즈니스 계층은 전혀 변화가 필요하지 않습니다.

비즈니스 계층과 프리젠 테이션 계층 간의 분리에도 동일한 원칙이 적용되어야합니다.

당신의 예에서, 나는 그렇게 말할 것입니다 ItemTagRequestProcessor 프레젠테이션 계층에 있어서는 안됩니다. 첫째, 프레젠테이션과 관련이 없습니다. 둘째, 요청 처리의 구현은 프레젠테이션 계층에 대한 관심이 아닙니다. 웹 응용 프로그램과 비교하여 a TagItemResponse 고객에게는 웹 (프레젠테이션) 레이어의 관심사가 있습니다. 인스턴스를 검색합니다 TagItemResponse 프리젠 테이션 계층 아래의 층의 관심사입니다.

비즈니스 계층과 지속성 계층 사이에 외관이 있을지 여부를 결정하는 것은 어렵습니다. 나는 보통 외관을 구현하지 않습니다. 게다가, 비즈니스 계층 방법에서 직접 지속성 계층 방법을 호출하는 데 문제가 없습니다. 동일한 원칙 만 고려한 경우 : 비즈니스 계층 구현에 영향을 미치지 않고 지속성 계층 구현을 변경할 수 있습니다.

친절한 안부,

로널드 와일드버그

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top