Webサービス契約設計 - 単一責任

Question

私は、ほとんどの開発者がWebサービスへの契約をどのように設計しているかを知りたいのです。私はサービスアーキテクチャー、特にWCFの初心者には全く新しいものです。

要するに、操作で返されるオブジェクトのタイプを確認したいと思います。サービス内の各操作で同じオブジェクトが返されますか？例えば

次の点を考慮してください 現在、私はに似ServiceBaseオブジェクトから継承し作成したすべてのサービス：したがって

 
public interface IAppResponse<TDto> where TDto : IDto 
{ 
    List<TDto> Data { get; } 
    ValidationResults ValidationResults { get; } 
    RequestStatus Status { get; } 
} 

：

 
public abstract class AppServiceBase<TDto> : DisposableObjectBase where TDto : IDto 
{ 
    protected IAppRequest Request { get; set; } 
    protected IAppResponse<TDto> Response { get; set; } 
} 

Responseのようなものを構成するリターンオブジェクトを表し派生したサービスは、同じオブジェクトで構成された応答を返します。 最初は、各サービスが1つのオブジェクトに責任を持つようにするために、良いデザインになると感じました。ほとんどの場合、これはうまくいっていますが、私のサービスが成長するにつれて、私はこのデザインに疑問を感じました。

例： あなたが書いている音楽サービスがあり、あなたのサービスの1つが「アルバム」になります。 基本的なCRUD操作を書いていて、ほとんどすべてがAlbumDtoのコレクションを返します。

アルバムの種類を返す操作を書きたい場合はどうなりますか？ （LP、Single、EPなど） オブジェクトAlbumTypesDtoがあります。このオブジェクトのためだけに新しいサービスを作成するか、アルバムサービスが多くの異なるオブジェクトを返すようにしますか？

複雑なサービスで、さまざまな戻り値の型があり、煩雑でデザインが貧弱だとは思いますが、おそらく1つまたは2つのサービス操作メソッドが過度に使用されている可能性があるために、

あなたはどう思いますか？

Answer 1

ドメインの問題の周りにサービスを設計することをお勧めします。 CRUDパターンをサービスに公開することによって、本質的にデータアクセス用のサービスを使用しています。このリスクは、あなたのビジネスロジックがあなたのサービスを消費しているものに結びつくことになります。

あなたのサービスは、あなたが解決しようとしている問題へのrelaventメソッドを公開する必要があります（これは典型的にはUI上の操作の上に緩くモデル）あなたはデータ契約が問題にもっと自然にフィットし始めるでしょうここから

あなたは、 "1つのサイズに合った"契約を作るのではなく、解決しようとしています。

Googleの「ドメインドリブンデザイン」には、これに関する参考資料がたくさんあります。