構建從頭開始的數據訪問層vs由Visual studio自動生成的數據訪問層

Question

我構建了Windows窗體，並且我有一些問題。

我想知道爲什麼我們必須從頭開始構建數據訪問層，儘管Visual Studio可以爲此生成代碼。

兩者的優點/缺點是什麼？

每個解決方案應該使用什麼情況？

Answer 1

對於需要向其應用程序添加數據訪問層（DAL）的開發人員，有許多不同的選項可用。我在這裏假設，當你說「Visual Studio可以爲此生成代碼」時，你指的是Microsoft的實體框架（EF），您可以使用它來從模式生成業務對象和存儲庫（反之亦然） 。還有其他一些方法可以用來生成數據訪問層（例如使用T4模板和代碼生成）。在考慮是否推出自己的數據訪問層時，一些因素起作用包括：

• 時間。可能是最大的因素（在我看來）。有很多參考資料可用於學習在很短的時間內啓動並運行EF數據層所需的約定。這是一種非常快速的將數據導入應用程序的途徑。過去只需從持久性存儲中加載和保存數據，現有的框架（如EF）可以輕鬆快速地支持事務和緩存等內容。如果編寫自己的DAL，從數據存儲中獲取數據所需的時間可能會更長，並且測試的時間肯定會比EF驗證的時間長。
• 特點。使用EF您可以獲得很多「開箱即用」功能。將這些添加到您的DAL需要一段時間。
• 經驗。從零開始編寫自己的DA層時有很多缺陷 - 爲什麼要重新發明輪子？從頭開始編寫好的DAL需要一些編碼經驗來做好（但是是一個很好的學習經驗和一個非常令人滿意的項目）
• 控制。如果您希望控制代碼的每個方面，您可能更願意編寫自己的DAL。雖然像EF這樣的框架可以通過多種方式進行配置，並且可以用於許多應用程序（特別簡單的應用程序），但大型應用程序（計算複雜或具有特定性能配置文件）的更復雜的需求可能更適合更多可調節的自定義DAL。例如，您可能不喜歡EF生成的SQL，或者您不喜歡加載子模型的方式。有大量的開源DAL爲開發提供了堅實的基礎，使得它可以輕鬆掛接到DAL的任何方面。
• 遺留代碼的存在。在某些極端情況下，如果您在現有的應用程序中工作，並且需要滿足現有的接口要求，或者適合現有的數據加載模式，則可能會更容易生成自己的DA層。這裏最好的選擇是編寫一個適配器層來使您的DAL適應現有的應用程序需求，從而將您的DA層從遺留代碼需求中解耦。

如果您打算編寫自己的DAL，我肯定會推薦查看一下存在的代碼生成選項。計劃您的架構經常更改，並能夠快速重新生成自定義DAL。類似Code Smith，MyGeneration和VS中的T4模板工具等工具可以在從頭開始編寫DAL時提供極大的幫助。