N-Tier 응용 프로그램의 메소드 레벨 문서

Question

내 상황 :

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

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

클라이언트는 생성 된 프록시를 사용하여 WCF 웹 서비스와 통신하는 Silverlight 응용 프로그램입니다. 결과적으로 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 또는 웹 서비스에서?

지금까지 내 생각 :

인터페이스에 메소드 사양을 작성하는 것이 가장 의미가 있다고 말합니다. 왜냐하면 그것이 소비되는 계약이기 때문입니다. 그러나 내 특정 상황에서 WebService와 DAL 사이에 이점이 없습니다.

• 나는 유일한 개발자이며, 문서가 필요한 별도의 웹 서비스-Guy 또는 클라이언트-Guy가 없습니다.
• 이것은 닫힌 아키텍처이며 웹 서비스는 공개되지 않습니다.
• 미래 에이 프로젝트를 수행하는 모든 사람은 모든 구성 요소에 액세스 할 수 있습니다 (문서가 어디에 있든 문서를 찾을 것입니다)

그래서, 당신은 그것에 대해 어떻게 생각하십니까? 이 경우 방법 수준 문서를 어디에 넣어야합니까?

Answer 1

대부분의 사람들은 웹 서비스가 DAL보다 더 많이 문서화 될 것으로 예상 할 것이라고 생각합니다 (특히 DAL이 대부분 생성 된 코드 인 경우 : 이들은 통과 방법이므로 추측하고 있습니다). 앞으로 일하는 사람들에 대한 DAL 의견에 웹 서비스 문서에 대한 포인터를 추가 할 것입니다.

그 이유는 두 가지입니다. 첫째, 웹 서비스는 실제 상호 작용 지점입니다 (따라서 더 많은 클라이언트가 추가 될 수있는 지점은 서비스를 문서화하는 것이 플러스임을 의미합니다). 두 번째는 DAL이 웹 서비스를 통해 "부가가치"를 제공하는 것처럼 들리지 않으므로 (설명 된 구성에서) 실제 상호 작용과 값의 지점을 지적하는 것이 의미가 있습니다.

DAL이 다른 고객의 재사용으로 위협을받은 경우 없이 웹 서비스 계층은 ... 분명히 다른 방식으로 기울어 지도록 (또는 중복 주석을 자동화하기 위해)를 변경합니다.