支持使用面向服務的體系結構傳輸富對象的設計模式？

Question

我有一個存在於服務器上的Employee類，我希望在Web服務中公開它，以便客戶端可以使用它。

這是我的班級：

public class Employee
{
    public CountryCode { get; private set;} 
    public EmployeeType {get; set;}

    public bool IsTaxable
    {
       get
       {
           return (CountryCode != Codes.CaymanIslands 
                  && Status != EmployeeType.Contract);
       }
    }

    public void Employee(EmployeeType type, CountryCode code)
    {
        EmployeeType = type;
        CountryCode = code;
    } 

    private void Employee() {}
}

私有構造函數和私有setter幫助此類強類型化，遵循DRY原則並確保它只能在有效狀態下實例化。

例如，我確保在構造函數中沒有設置IsTaxable ，而是根據其他類屬性動態評估。 這樣，如果修改了EmployeeType ，則IsTaxable的結果將反映此更改。 我使用這個簡單的例子來強調這個對象具有豐富的邏輯。

假設這個Employee類存在於服務器上，我希望在客戶端上訪問它。 我構建了一個WebService（在.NET中我將使用WCF），公開該類並使用開箱即用的工具連接，並且能夠在我的客戶端中使用此類。

問題在於，這樣做會導致我失去大部分封裝邏輯 。 在接收端，客戶端無法使用它的私有setter，隱藏的構造函數，IsTaxable屬性中的邏輯等來查看這個豐富的類。相反，在客戶端我會看到一個像這樣的輕量級類：

public class Employee
{
    public CountryCode { get; private set;} 
    public EmployeeType {get; }
    public bool IsTaxable {get; }
}

現在，客戶端可以通過執行以下操作來實例化處於無效狀態的類：

Employee e = new Employee();
e.EmployeeType = EmployeeType.Contractor;
e.IsTaxable = true;

失去富裕對象只是服務導向生活的一個事實，而我們必須要忍受這樣的事情嗎？

此類服務轉移對象是否僅僅是為了傳輸信息而被視為弱數據傳輸實體，並且應該是只讀的。

在客戶端，您是否應該（如果需要）將它們包裝在更豐富的對象中？

有沒有任何方法可以通過線路傳遞邏輯完整的富對象，還是真的需要？

是否有任何已建立的模式來處理這種情況？

Answer 1

在查看設計模式之前，您需要首先考慮的是您實際需要進行邏輯的位置，以及當“流氓”客戶端更改通過網絡接收的數據時實際發生的情況。

大多數客戶端 - 服務器體系結構的設計方式是，無論客戶端嘗試做什么，都必須由服務器進行驗證。 因此，如果客戶端決定將IsTaxable更改為true，或更改Employee的名稱或ID等，則它將不會對存儲在服務器端的實際數據產生任何影響。 客戶端必須執行操作以更新服務器上的數據，並且只有在他有權這樣做時才將數據傳播到數據庫和系統的其余部分。

客戶端始終處於“風險”狀態（可由用戶操縱，黑客入侵，嗅探電線等），因此服務器必須足夠安全以抵御這種情況。

“傳輸對象”通常僅用於傳輸數據。 然后，任何邏輯由客戶端執行（例如，將數據格式化為更加用戶友好的表示），或者由服務器執行。 如果客戶端需要對數據執行操作，則需要請求服務器執行此操作（以便集中更新）。

因此，在您的情況下，您的Web服務需要公開客戶端的操作，以執行您可能需要的任何邏輯。

您可能想要了解的另一件事是如何創建Contract First Web服務。 這被認為是最佳實踐，因為它不僅可以確保您的Web服務可以與其他平台（例如Java）互操作，還可以讓您考慮要向客戶公開的操作和數據，並幫助您避免制作錯誤（例如期望只有服務器有權訪問的對象的實例）。

契約優先意味着您創建描述操作的WSDL和描述要以XML傳輸的消息和對象的XSD。 他們只是從那些WSDL和XSD文檔自動生成代碼。

Answer 2

您不能為任意客戶端執行此操作，但如果您同時控制客戶端和服務器，則可以向客戶端添加對包含Employee類的程序集的引用，然后將此類型重用於WCF合同。

在Visual Studio中，可以使用“添加服務引用”/“高級”/“在引用的程序集中重用類型”來執行此操作。

失去富裕對象只是服務導向生活的一個事實，而我們必須要忍受這樣的事情嗎？

是的，這是真的。 在真正面向服務的體系結構中，您不共享客戶端和服務器之間的行為，只交換消息。 但是，如果您在控制雙方的客戶端 - 服務器體系結構中使用WCF，則可以使用上述方法。