實體數據框架和Web應用程序體系結構

Question

我正在創建一個Web應用程序並首先使用實體​​框架。我創建了實體數據模型，現在我不確定，現在該怎麼做。

前提：我的數據庫真的很簡單（Rating，WebPage，Visitor）和數據庫表對應的業務對象。

我的建議是3層架構，但如何使它？

1. 這是好主意，創造局部類具有相同的名稱作爲實體框架對象（評級，訪問者），並在這裏宣佈新方法（GetAverageRating（）...）？或者更好地創建一些VisitorProvider，RatingProvider和放置邏輯？

2. 最好在BLL和表示層使用EF對象，或者我應該在BLL圖層上創建自己的BO對象並將EF對象轉換爲BO？

3. 我想，這是更實際的使用我的DAL靜態方法比在BLL上實例化類。你同意嗎？

你能推薦我一些最佳做法嗎？我有很多想法如何創建它，但我不知道什麼是正確的。

Answer 1

3層架構非常流行，但它的真正含義是什麼？

1. 表示層
2. 應用層
3. 數據庫層

如果你問什麼每層意味着你可以確信你會得到幾個不同的答案。您還可以將每個層爲底層，並建立分層地獄一樣：

1. 客戶端展現層
2. 服務器側視圖層
3. 控制器層
4. 服務門面層
5. 服務層
6. 域對象層
7. 存儲庫+工廠層
8. ORM層
9. 存儲過程層
10. 數據庫視圖層
11. 數據庫表層

WTF？這只是應用程序可以輕鬆架構的例子。如果你堅持只有鄰居可以交換數據，並且你決定添加特殊類型的對象才能在層間交換，而不是通過多層對象流動唱歌，那麼情況會更糟。

添加您需要的圖層，使其更加適合開發應用程序，並且可以合理區分應用程序規模所需的關注點和可維護性。您可以簡單地做最簡單的應用程序，只需幾周即可使用，並且必須儘快開發。在這種情況下，只需使用ASP.NET Web窗體和數據源控件（或ASP.NET動態數據），即可在幾天內完成此操作。它可能是非常可擴展的，但在這種情況下，它正是您快速實現應用程序所需的東西。如果您需要它，編寫圖層並在可維護性和可擴展性方面做所有事情是合理的。另一種快速原型技術是ASP.NET MVC腳手架，它可以創建可以進一步修改的應用程序的快速多層骨架。

1. 兩種方法都是正確的，它只取決於你喜歡的方法。第一個稱爲active record pattern，但它並不經常用於實體框架。第二種方法更受歡迎。你可以直接在一些中產階級中使用EF，這些產品叫做Provider（通用名也是Service）。這個類將執行數據訪問邏輯和業務邏輯。在更復雜的應用程序開發者喜歡以某種方式將EF包裝到分開的類repository pattern後，並從服務或直接從Web應用程序調用存儲庫。後面的代碼或控制器（取決於業務邏輯的數量）。嘗試在沒有存儲庫的情況下先做。我個人認爲，只有當他們瞭解EF本身時，人們才應該開始使用存儲庫。
2. 這兩種方法都是正確的。在一個簡單的應用程序中，完全可以使用POCO類（EFv4.x）創建EF模型並在所有圖層中使用它們。如果您使用的是ASP.NET MVC，則可以發現您需要特殊的類作爲視圖模型，以充分表示您的各個視圖的需求。在一個更復雜的應用程序中，您可以使用從業務層公開的單獨對象 - 如果業務層作爲遠程服務（WCF）公開，則尤其如此。
3. 這取決於你如何編寫這些DAL方法 - 它是absolutely necessary to not share the EF context among requests！這也取決於你是否想寫一些測試。由靜態方法定義的層是直接針對可測試體系結構的地方，您希望單元測試只是單層（使用EF進行單元測試可能很困難）。它也取決於你是否想使用基於實例的依賴注入。