2

ほとんどの開発者が自分の Web サービスに対するコントラクトをどのように設計しているのか知りたいです。私はサービス アーキテクチャにまったく慣れておらず、特に WCF には慣れていません。

要するに、操作で返されるオブジェクトのタイプを知りたいのですが、サービスの各操作は同じオブジェクトを返しますか?

たとえば、次のことを考えてみましょう: 現在、私が作成するすべてのサービスは、次のような ServiceBase オブジェクトから継承されます。 

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

Response次のようなものを構成する戻りオブジェクトを表します。 

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

したがって、どの派生サービスも、同じオブジェクトで構成される応答を返します。最初は、各サービスが 1 つのオブジェクトを担当するように強制されるため、 を使用するのは良い設計だと思いました。ほとんどの場合、これでうまくいきましたが、サービスが成長するにつれて、この設計に疑問を抱くようになりました。

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

アルバムの種類を返す操作を書きたい場合はどうでしょう。(LP、Single、EP など) オブジェクト AlbumTypesDto があります。このオブジェクトのためだけに新しいサービスを作成しますか?それとも、アルバム サービスでさまざまなオブジェクトを返すようにしますか?

いくつかの異なる戻り値の型を持つ複雑なサービスは扱いにくく、設計が貧弱であると想像できますが、1 つまたは 2 つのサービス操作メソッドだけがやり過ぎになる可能性があるため、まったく新しいサービスを作成します。

どう思いますか？

4

1 に答える 1

1

ドメインの問題に合わせてサービスを設計することをお勧めします。サービスで CRUD パターンを公開することで、基本的にデータ アクセスにサービスを使用することになります。これのリスクは、ビジネスロジックがサービスを消費しているものに行き着くことです。

サービスは、解決しようとしている問題に関連するメソッドを公開する必要があります (通常、UI の操作に大まかにモデル化されます)。

ここから、「フリーサイズ」のコントラクトを作成するのではなく、解決しようとしている問題にデータ コントラクトがより自然に適合し始めることがわかります。

良い手始めとして、Google の「ドメイン駆動設計」ですが、これに関する参考資料はたくさんあります。

于 2010-11-21T07:56:11.513 に答える