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服務合約設計 - 單責任

回答

相關問題