升級.NET應用程序數據層

Question

我爲一家開發超大規模數據應用程序的公司工作。該應用程序最初是在十年前創建的，因此迫切需要升級。我被賦予了調查和實施數據層升級的任務。

目前，它使用的系統的業務對象都基於/擴展DataRow對象，即 - 每個對象或多或少與數據庫中的一行有關。該應用程序目前不是面向對象的，但是這會導致很多問題，我們希望按照OO方向移動。

因此，我們正在尋找開始使用.NET實體框架並創建一個.edmx文件。這個想法只是將所有的SQL數據庫表拖放到.edmx設計器上，並讓它創建其相關的數據對象。

現在，在我的腦海裏（作爲一個面向對象的開發者），我正打算手動創建新的業務對象，並填充它們從的.edmx生成的數據對象從查詢新的數據層返回。這將允許使用接口簡單分離各個層。

的問題是，老闆說，沒有足夠的時間來改寫百元左右的業務對象類，他建議使用的.edmx產生的在整個應用程序數據對象。

在我的腦海裏每思說：「不......不創建數據層和整個系統之間的耦合」，但老闆說，他已經看到了網上的文章促進這一點。

所以我的問題對你們是這些：（請提供你的答案爲1正當理由和2）

1. 這是一個可行的解決方案（即使是短期）？

2. 有沒有更好的/替代的解決方案，從生成的數據對象創建單獨的業務對象？

3. 有用來創建從生成的數據對象單獨的業務對象，而不是手動複製和粘貼一個更好/更簡單的方法？

我明白這些問題有點主觀，但我已經提供了儘可能多的具體信息，我真的可以做一些關於這個問題的建議。

Answer 1

這是一個常見問題，可能是每個遺留系統人員嘗試升級。

我沒有看到任何您創建「數百」業務對象並將數據從EF數據對象複製到您的數據的任何一點？您仍然與EF和您的業務對象耦合！

要使用耦合IoC通過，應考慮在數據訪問層與業務層之間保持分離。當然，你可以用很少的成本/時間來切換ORM。這是separation of concern的美麗。在軟件行業，如果您現在想要降低成本，您可能需要長期支付更多費用（如果您需要再次更改或ORM）。

試着在質量方面與你的老闆進行談判，現在可能有點貴，但從長遠看肯定會有所收穫。您可以考慮使用EF Code First。在數據訪問層設計上，這肯定會比「數據庫優先」更好地掌握。

您也可以編碼生成器來生成您想要的數據訪問層，這樣可以節省數百個工時，另外您可以更好地實現模塊。我建議你去CodeSmith Generator。有一點學習曲線，但它是值得的。

請記住，分離數據訪問不是升級遺留系統的解決方案。在很多情況下，我看到升級和維護核心功能成爲世界上最難的工作。除非業務人員在面臨失敗時決定進行真正的升級，否則沒有什麼可做的。

嘗試確定核心組件，並且DAL必須是要升級的核心組件之一。

Answer 2

當我開始發展我當前的應用程序，我選擇使用代碼首先，以免產生巨大的EDMX。我讀到他們正在對該設計師進行改進（將其拆分等），但實際上，我不想嘗試使用edmx，因爲我們必須創建100多個對象。

我開發了一個小應用程序來讀取表格併爲代碼優先創建POCO對象（我認爲現在有工具可以做到這一點），然後爲所有這些對象創建一個表示上下文containsinig DbSet的類。

當我試圖將這些對象直接用於前端的MVC應用程序時發現，我得到的序列化問題試圖將它們放入具有循環引用問題的網格中（大量使用json序列化）。所以，我選擇創建ViewModels，並且在我不需要速度的情況下，使用像AutoMapper這樣的工具來映射表< - > ViewModel。在我確實需要速度的情況下（如列表屏幕），我寫了實際的linq查詢來將結果轉換爲視圖模型對象。我發現的唯一問題是視角模型必須非常平坦。

對於你來說，這不是一個真正的答案，而是通過這個過程的一些經驗。

Answer 3

的問題是，老闆說，沒有足夠的時間來 重寫百元左右的業務對象類，他使用的.edmx在整個 應用程序生成的數據對象表明 。

1. 這是一個可行的解決方案（甚至短期）？ &
2. 是否有更好的/替代的解決方案來從生成的數據對象中創建單獨的業務對象？ &
3. 是否有更好/更簡單的方法從生成的數據對象中創建單獨的業務對象，而不是手動複製和粘貼？

ANS：你可以嘗試Sybase PowerDesigner可以逆向工程和生成C＃代碼爲您服務。 或者您可以嘗試CodeSmith爲您生成代碼。這些工具節省您的時間。

還有其他的框架，如Developer Express XPO和DataObjects.Net etc ...或LLBLGen Pro你可以試試。這些可以分開你的關注。