WCF服務和實體框架n層應用程序問題

Question

我正在開發WCF服務，它是較大系統的一部分。該服務將提供一些業務邏輯，並將通過實體框架（使用模型優先）連接到數據庫。我發現有許多不同的方式與WCF服務（基本實體，DTO，自我跟蹤實體，POCO等）聯合實體框架。我的基本要求：

• 的服務是瘦客戶機（和其他服務）所建，大部分的邏輯是在其一側，所以它不是任何CRUD應用程序（WCF數據服務是不適合我）
• 不同的客戶需要不同的粒度級別的數據，所以在數據庫中的同一實體會有不同的數據合同

由於我的要求我的眼光應該如何構建最接近（我認爲這是最接近到DTO方法）： http://www.codeproject.com/Articles/127395/Implementing-a-WCF-Service-with-Entity-Framework

但我認爲數據訪問層應該與服務的邏輯（2個程序集：項目，名稱空間，DLL，但作爲一個應用程序工作）分開。在這種情況下，我會遇到一些問題：這兩層應該分別做什麼：應該在服務中完成所有的邏輯，並且將DAL用作CRUD？或者應該服務只負責明確的業務邏輯，而整個數據庫邏輯（使用linq的具體查詢）將在DAL（通過DAL公開的更多特定方法）中完成？還有什麼是重要的哪些對象應該發送這些2層：數據契約，實體或附加模型？

在上述情況下，我的方法可以嗎？

Answer 1

在SOA之前，N層或3層架構一般都有專門的業務層。如果您對問題的分離感覺足夠強烈（或者如果您認爲可能會從非服務用戶那裏重用您的業務功能），爲什麼不將業務邏輯移出服務層？ （但不要把業務邏輯在DAL）

但是，如果你的服務層確實提供數據查詢服務，以及交易者，則不需要這些服務的業務層 - 看看CQRS在這裏輸入設計模式。

如果您需要控制實體的XML格式（名稱，xmlns等），您可能需要構建自定義的WCF DataContract或MessageContract實體。然而，如果你不關心跨越線路的數據是什麼樣子的，你可以簡單地使用EF實體類（只要它們不是上下文綁定的 - 即，如果在EF上使用POCO）。如果您沒有將POCO與DataContract等屬性相關聯，則DataContractSerializer的默認行爲是序列化公共屬性。

所以，你可以風與以下彙編 '層'（自下而上）的EF

• DAL實體（無論是ObjectContext的約束或POCO）
• EF DAL
• 業務層（事務服務方法只 - 繞過查詢）
• 可能彼此獨立的WCF實體，在那裏你映射你的POCO/DAL BE對DataContract/MessageContract
• WCF服務層