Web服务合约设计 - 单责任

我很好奇，看看大多数开发人员如何去设计合同，他们的网络服务。我对服务体系结构很陌生，特别是对于WCF的新手。Web服务合约设计 - 单责任

总之，我想看看你是返回在您的操作对象的类型，并不会在你的服务的每个操作返回相同的对象？

例如，请考虑以下几点：目前，我创建一个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; } 
}

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

借此例如：你有你写的音乐服务与您的服务之一将是“相册”。所以你写了基本的CRUD操作，他们几乎都返回一个AlbumDto的集合。

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

我能想象一个复杂的服务与多家不同的返回类型是繁琐，设计不良，又为了什么，也许，只有一个或两个服务的操作方法是矫枉过正写了一个全新的服务。

您认为如何？

来源

2010-11-21 Daniel

这是围绕您的域问题设计服务的好主意。通过在服务上暴露CRUD模式，本质上您正在使用数据访问服务。这种风险是你的业务逻辑将最终在任何消费你的服务。

您服务应公开relavent你正在试图解决这个问题的方法（其中松散模式到操作上通常是UI）

从这里，你会看到你的数据契约开始更加自然贴合的问题你正试图解决，而不是创建“一刀切”的合同。

对于一个很好的入门，谷歌“领域驱动设计”但有大量的参考材料这一点。

来源

2010-11-21 07:56:11 Slappy

感谢您的回答Slappy。过去一年，我一直在使用DDD，但到现在为止，并不需要服务层。你能否澄清一下你的意思：“这种风险是你的业务逻辑最终将导致任何消耗你的服务。” 因此，根据您的回应，我不应将我的合同操作限制为单一回复类型，而应确保他们只返回与问题相关的对象。我将继续阅读DDD和服务层设计。 – Daniel 2010-11-21 20:03:09

业务逻辑消耗CRUD例程。在您的WEB服务上实现CRUD将意味着您的客户（在本例中为silverlight应用程序）将承载业务逻辑。在我看来，我会将业务逻辑封装在Web服务中，以便您的Silverlight应用程序只需要关注演示。 – Slappy 2010-11-22 22:10:07

Web服务合约设计 - 单责任

回答

相关问题