WCF和繼承

Question

我正在一個項目中，我有一個抽象類的約會。有鍛鍊，膳食和測量，都來自約會。我的建築看起來像這樣至今：

道 - 與數據訪問層是實體框架4現在使用T4模板 WCF Silverlight客戶端，ASP.net MVP，移動客戶端

POCO類，我會把商業規則放在POCO類中？或者將我的實體映射到具有規則的業務對象，然後將這些實體映射到DTO並將它們傳遞給WCF？當我通過DTO時，我是否通過類型預約？或者爲鍛鍊或膳食等每個子類寫一個服務方法？

我還沒有找到任何好的材料使用表每種類型的繼承和WCF。

在此先感謝！

-ajax

Answer 1

它主要取決於你需要的複雜性。您正在使用POCO課程，這是很好的起點。您現在必須選擇要構建多麼複雜的應用程序，您要添加多少業務邏輯以及要向客戶展示什麼？

POCO實體可以只是DTO，或者您可以通過將業務方法和規則直接添加到實體中來將POCO實體轉換爲業務對象 - 您將實體轉換爲活動記錄模式或Domain對象。我沒有看到任何理由將您的POCO映射到另一組業務對象。

在WCF服務中公開POCO實體是最簡單的方法。您可以使用直接與Appointment類一起工作的操作。此外，您必須提供有關從約會派生的所有類別的服務信息 - 請檢查KnownTypeAttribute和ServiceKnownTypeAttribute。使用實體通常意味着服務呼叫超出需要的傳輸 - 這對於互聯網連接速度慢的移動客戶端可能是個問題。在暴露聚合根實體（包含對其他實體和實體集合的引用）時，您必須瞭解一個特殊點 - 如果您沒有完全控制客戶端應用程序，並且允許客戶端發送完全修改的對象圖你不僅要驗證每個實體，還要驗證客戶只改變了他被允許的內容。例如：假設客戶想修改訂單實體。您將Order發送給所有OrderItem實體，並且每個項目都將引用其Product實體=完整對象圖。如果不是修改Order和OrderItems客戶端更改任何產品（例如價格），會發生什麼情況？如果您沒有在WCF公開的業務邏輯中檢查它並將修改後的對象圖傳遞到EF上下文中，它將修改數據庫中的價格。

如果您決定使用業務對象等實體，通常不會公開這些實體，而是創建大量的DTO。每個操作都將使用精確定義的DTO來請求和響應。該DTO將僅攜帶真正需要的信息 - 這將減少服務呼叫的數據有效負載，並避免傳遞產品的修改價格，因爲您將簡單地定義您的DTO不會從客戶端轉移價格甚至整個產品。該解決方案實施起來耗時更多，並增加了額外的複雜性。

因爲我已經提到了對象圖，我必須澄清在使用它們時存在另一個隱藏的複雜級別：更改跟蹤。 EF上下文需要知道對象圖中發生了哪些變化（至少哪些OrderItem已被修改，哪些已被添加或刪除等）以實現正確的持久性。跟蹤和多層解決方案是一個挑戰。最簡單的解決方案不會跟蹤更改，而是對EF使用附加查詢。該查詢返回對象圖的實際持久狀態，並將修改的對象圖與其合併（需要特別注意併發檢查）。其他解決方案在實體中使用一些跟蹤支持 - 檢查Tracking changes in POCO和Self-tracking entities。但這僅限於實體。如果您想跟蹤DTO中的更改，則必須實施自己的更改跟蹤。您還可以閱讀MSDN雜誌關於多層應用程序和EF的文章： Anti-Patterns To Avoid In N-Tier Applications; Building N-Tier Apps with EF4