Question

我很好奇大多数开发人员如何设计合同到他们的Web服务。我是服务架构的新手，尤其是WCF的新手。

简而言之，我想知道您在操作中返回的对象类型，并且服务中的每个操作是否都返回相同的对象？

例如，请考虑以下事项：目前，我创建的所有服务都从ServiceBase对象继承，该对象看起来类似于：

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

<TDto>表示返回对象，它包含以下内容： <TDto>

Response

因此，任何派生服务都将返回由同一对象组成的响应。最初，我觉得这将是一个很好的设计，因为这会强制每个服务负责一个对象。在大多数情况下，这已经成功，但随着我的服务的增长，我发现自己质疑这种设计。

以此为例：您正在撰写音乐服务，其中一项服务将是“专辑”。所以你编写了基本的CRUD操作，他们几乎都返回了AlbumDto的集合。

如果要编写返回相册类型的操作，该怎么办？（LP，Single，EP等）所以你有一个对象AlbumTypesDto。您是仅为此对象创建新服务还是让您的相册服务返回许多不同的对象？

我可以想象一个具有多种不同返回类型的复杂服务，这些服务很繁琐且设计很差，但是为可能的只有一两种服务操作方法编写一个全新的服务是过度的。

您怎么看？

Answer 1

围绕域名问题设计服务是个好主意。通过在服务上公开CRUD模式，基本上您使用服务进行数据访问。这样做的风险在于您的业务逻辑将最终消耗在您服务的任何内容上。

您的服务应该公开与您要解决的问题相关的方法（通常会在UI上的操作上松散地建模）

从这里，您将看到您的数据合同开始更自然地适合您要解决的问题，而不是创建“一刀切”的合同。

对于一个好的入门者，谷歌“领域驱动设计”但是有很多参考资料。

Web服务合同设计 - 单一责任

1 个答案: