在使用實體框架時，POCO是正確的選擇嗎？

Question

我一直在閱讀關於POCO（普通舊CLR對象）的一段時間，但仍然無法找到使用它而不是使用實體框架的自動生成的部分類的真正附加價值？ 還有一件事是最好直接從表示層使用我的實體框架，還是創建BLL會更好？

Answer 1

POCO的主要好處是您可以將它傳遞給不需要了解Entity Framework的類，庫或程序集來完成它的工作。

記住單一責任原則 - 您的DAL應該知道EF，但您的域名不應該，而且您的表示層也不應該，因為EF處理數據訪問而這些層不處理。 將EF生成的類對象傳遞到這些層通常意味着您需要使這些層知道EF，破壞SRP並使單獨測試這些層變得更加困難。

為了回應阿里在下面評論中的進一步詢問，這里有一個擴展的解釋。

在更復雜的應用程序中，您需要將邏輯分解為單獨的關注點 - 數據訪問，業務邏輯，表示（可能還有更多）。

當實體框架處理數據訪問時，它駐留在數據訪問層中 - 在這里，您將看到POCO和EF生成的類之間幾乎沒有區別。 這很好，因為該層已經了解了Entity Framework。

但是，您可能希望將數據傳遞到業務邏輯層 - 如果您使用EF生成的類執行此操作，那么您的業務邏輯層也必須了解實體框架，因為EF類依賴於EF特別提供的許多內容。 這樣做是為了消除業務邏輯層應該具有的隔離 - 您需要這種隔離，這樣您就可以通過從虛假數據訪問層將已知數據注入到類中來正確地對其進行單元測試，如果您讓這個非常難以做到業務邏輯層了解EF。

使用單元測試，您應該測試圖層功能，而不是第三方庫的功能 - 但是使用EF，您最終會測試很多EF的功能，或者您自己的功能非常依賴於EF的功能。 這不好，它可以掩蓋錯誤或問題。

刪除對EF生成的類的業務邏輯依賴性還允許您從數據訪問層將層移動到遠程位置 - 您甚至可以將其粘貼在Web服務之后，它將非常高興。 但是你只能用POCO來做這件事，你不能用EF生成的類來做這件事。

POCO在大型，復雜的多層應用程序中真正發揮作用 - 如果你沒有分層你的應用程序，那么你就不會看到一大堆好處。

所有這些都是我的觀點，我只是一個有經驗的編碼員 - 我不是編碼搖滾明星，所以其他一些評論者可能希望進一步擴展我的答案......

Answer 2

POCO的真正好處是您可以首先使用代碼和EF遷移。 如果您不打算首先使用代碼，則可以使用設計器生成的類。

如果您有一個大型應用程序，您應該創建一個單獨的BLL，但如果您的應用程序非常小，您可以直接使用表示層中的EF類。

Answer 3

在ORM中使用POCO類允許您以更簡單的方式為該代碼創建測試。 它還允許您在模型對象（PO​​CO類）和數據訪問代碼之間有一層抽象，因此如果需要，您可以交換數據訪問代碼（例如，用於NHibernate的EF）。

我過去曾使用過POCO模型，我可以告訴你它對大型企業項目和大型開發團隊很有用，模型的更改經常發生，而EF默認使用的整體文件模型不能很好地擴展。 很難看到小項目或快速應用程序開發的好處。

TLDR版本：如果您問自己POCO和代碼的優點是什么，您可能無法從使用它們中獲得任何收益。