0


0

私の状況:

私のアプリケーションのデータリクエストチェーンは次のようになります。

(クライアント) - >(WebService) - >(SQLまたはOLAP Cube)

クライアントは、生成されたプロキシを使用してWCF Webサービスと通信するSilverlightアプリケーションです。 これは認証を行い、DALコンポーネントを使用してSQL DBとOLAPキューブにアクセスします。*基本的にはリクエストを転送するだけです。 したがって、各方法は4つの異なる場所に存在します。

// WCF Webservice interface and implementation (used by client)
パブリックインターフェイスICatalogServiceパブリッククラスCatalogService:ICatalogService

// DAL interface and implementation (used by webservice)
パブリックインターフェイスICatalogDataAccessLayerパブリッククラスCatalogDataAccessLayer:ICatalogDataAccessLayer

さて、私の質問ですが、これらのメソッドを明確に指定するためのドキュメントをどこに置くべきですか? クラスレベルかインターフェースレベルか、DALかWebサービスか。

私の考えはこれまでのところ:

メソッド仕様をインターフェースに記述するのが最も理にかなっていると思います。 しかし、私の特定の状況では、WebサービスとDALの間に利点はありません。

  • 私は唯一の開発者です、ドキュメントを必要とする別のwebservice-guyまたはclient-guyはありません。

  • これは閉じたアーキテクチャです、ウェブサービスは公開されていません

  • 将来このプロジェクトに取り組む人は誰でも、プロジェクトのすべてのコンポーネントにアクセスできるようになります(そして、どこにいても、ドキュメントを見つけるでしょう)。

それで、あなたはそれについてどう思いますか? この場合、メソッドレベルのドキュメントをどこに置くべきですか?

1 Answer


1


私は、ほとんどの人がWebサービスがDALよりも文書化されていることを期待していると思うでしょう(特にDALが主に生成されたコードであるならば。 将来的にWebサービスを扱う人のために、WebサービスのドキュメントへのポインタをDALのコメントに追加します。

その理由は2つあります。 まず、Webサービスが相互作用の本当のポイントです(したがって、さらにクライアントを追加できるポイントです。つまり、サービスを文書化することはプラスになります)。 2つ目は、DALは実際にはWebサービスを介して「付加価値」を提供するようには見えないため(説明されている構成で)、インタラクションと価値の実際のポイントに戻ることは意味があります。

DALがWebサービス層を介さずに他のクライアントによる再利用を脅かされたことがある場合…​ 明らかにそれは物事を逆に傾くように(または重複するコメントを自動化するために)変更します。