0

내 상황 :방법 수준의 문서

내 응용 프로그램의 데이터 요청 체인은 다음과 같습니다

(Client) -> (WebService) -> (SQL or OLAP Cube) 

클라이언트가 통신하기 위해 생성 된 프록시를 사용하는 Silverlight 응용 프로그램입니다 WCF 웹 서비스. DAL 구성 요소 인 을 사용하여 권한 부여를하고 SQL DB 및 OLAP 큐브에 액세스하는 것은 기본적으로 요청을 전달하기 만합니다. 따라서, 각각의 방법은 네 개의 다른 장소에 존재 :

// WCF Webservice interface and implementation (used by client) 
public interface ICatalogService 
public class CatalogService : ICatalogService 

// DAL interface and implementation (used by webservice) 
public interface ICatalogDataAccessLayer 
public class CatalogDataAccessLayer : ICatalogDataAccessLayer  

가 지금은 문서를 넣어해야 내 질문에 명확하게 이러한 방법을 지정하려면? 클래스 또는 인터페이스 수준, DAL 또는 웹 서비스?

내 생각이 지금까지 :

나는 그것이 소비되고있는 계약이기 때문에이 인터페이스에 메소드 스펙을 작성하는 가장 적합한 말할 것입니다. 그러나 내 특정 상황에서 웹 서비스와 DAL 사이의 이점을 볼 수 없습니다 :

  • 을 나는 유일한 개발자입니다,이 별도의
  • 이가있는 문서를 필요로 웹 서비스-사람 또는 클라이언트 사람 폐쇄 형 아키텍처는 웹 서비스가 (그들이 어디에 있든지, 그리고 문서를 찾을 수 있습니다) 앞으로이 프로젝트에 참여 모두가, 그래서

그것의 모든 구성 요소에 액세스 할 수 있습니다

  • 공개되지 않습니다, 당신이 무엇을 할 그것에 대해 생각해? 이 경우 메서드 수준 문서는 어디에 배치해야합니까?

  • 답변

    1

    대부분의 사람들은 웹 서비스가 DAL보다 더 많이 문서화 될 것이라고 기대할 것입니다 (특히 DAL이 주로 생성 된 코드 인 경우 : 나는 이것이 통과 방식이기 때문에 추측하고 있습니다). 나중에 함께 작업하는 사람들을 위해 DAL 주석에 웹 서비스 문서에 대한 포인터를 추가 할 것입니다.

    이유는 두 가지입니다. 첫째, 웹 서비스는 상호 작용의 진정한 지점입니다. 따라서 더 많은 클라이언트가 추가 될 수 있습니다. 즉, 문서화 된 서비스를 갖는 것이 더 좋습니다. 두 번째는 DAL이 실제로 웹 서비스를 통해 "부가가치"를 제공하는 것처럼 들리지 않는다는 것입니다 (설명 된 구성에서). 그래서 상호 작용과 가치의 진정한 시점을 다시 지적하십시오. DAL 이제까지없이 다른 클라이언트 에 의해 재사용 웹 서비스 계층을 위협 한 경우

    는 ... 분명히 그것은 다른 방법으로 주위를 숙이고 (또는 중복 의견을 자동화하는) 일을 변경합니다.