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

Question

我很想知道大多数开发人员是如何为他们的 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; }
}

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

以此为例： 你有你正在写的音乐服务，你的服务之一是“专辑”。 因此，您编写基本的 CRUD 操作，它们几乎都返回 AlbumDto 的集合。

如果你想编写一个返回专辑类型的操作怎么办。 （LP、单曲、EP 等） 所以你有一个对象 AlbumTypesDto。您会为这个对象创建一个新服务还是让您的相册服务返回许多不同的对象？

我可以想象一个具有多种不同返回类型的复杂服务是繁琐且糟糕的设计，但编写一个全新的服务可能只是一种或两种服务操作方法是矫枉过正的。

你怎么看？

Answer 1

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

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

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

作为一个好的开始，谷歌“领域驱动设计”但是有很多关于这方面的参考资料。