wcf 服務和asp .net 表示層

Question

我有 wcf 服務，它負責數據庫交互和業務邏輯。 它還具有用於業務對象的 class 庫。 我想要 wcf 服務返回對象列表。 我是否應該為我的 asp .net 項目（正在使用服務）創建另一個 class 業務對象庫，以便 asp .net 項目可以理解 object 類型？

Answer 1

您應該在服務和 asp.net 項目之間共享 class object 庫。 這就像您整個項目的“中間件”。 這將避免不必要的重復。 基本上，只需將所有業務對象移動到不同的項目並將其包含到 wcf 和 asp.net 解決方案中。

Answer 2

並不真地。 當您通過 visual studio 使用添加服務引用添加對 web 服務的引用時，您將獲得每個 object 的代理類，以在 web 服務中使用

Answer 3

服務的標准做法是返回DTO而不是業務對象：在表示層中使用您的業務對象會將其與業務邏輯緊密耦合，並且大多數時候您不希望這種耦合。 還要記住，您通過網絡發送的所有內容都應該是可序列化的，您的業務對象可能是可序列化的，也可能不是可序列化的。

所以我會說是的，你很可能想用 DTO 創建一個不同的庫，並將其中的類用作數據契約。 重復並不是真正的問題，因為它保證了合同的一定穩定性，並且可以使用AutoMapper等工具將您的業務對象 map 發送到 DTO。

讓我們考慮在表示層 (ASP.NET) 和服務層之間共享一個公共業務 class 庫的方法的優點和缺點。

優點：

• 易於實施：只需將現有項目連接到 asp.net，將您的類標記為可序列化即可
• 非冗余：你有一個 class 代表一個概念

缺點：

• 您的類可能無法序列化
• 很容易“滑倒”並使用業務 class，您不應該在不通過服務的情況下直接在表示層中使用它
• 緊耦合：更改業務類，服務層和表示層都可能中斷
• 為什么我們再次使用服務？

將此與創建 DTO 庫進行比較：

優點：

• 接口（數據合同）定義明確：這個庫中的所有內容都是一個通信 object
• 序列化沒有問題
• 表現與服務松耦合：借助數據契約的抽象，業務邏輯的變化最多反映到DTO映射層

缺點：

• 你需要 map 你的對象到 DTO（認為 AutoMapper 對此很有幫助）
• Dmitriy 引用了重復，雖然不必要是主觀的：我想我已經向你展示了為什么需要它。 此外，你不應該害怕在你的應用程序的不同部分引入相同概念的不同視圖：我還沒有找到一個 model 完美適合重要程序中的每個用例。