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; }
}

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

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

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

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

你怎么看？

4

1 回答 1

1

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

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

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

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

于 2010-11-21T07:56:11.513 回答