從數據集遷移到EntityFramework

我目前正在研究可能的方法，我們可以重構我們的代碼庫，以使其更易於使用。從數據集遷移到EntityFramework

該應用程序是相當大的Asp.Net Webforms應用程序，所有數據設置/檢索通過Web服務發生。目前，這些WebServices返回數據集，其中包含從存儲過程返回的一個或多個表。代碼庫與ASP代碼緊密相連，後臺在多個地方調用WebServices，大多數業務邏輯發生在代碼隱藏或存儲過程中。

現在有一段時間了，我們一直在尋找可能的方式來更新應用程序，並實現代碼庫的現代化。我們不能（也不想）重寫整個應用程序，但如果我們能夠開始將它逐步移植到更新的體系結構中，那將是非常好的。我研究了MVP體系結構，它似乎與我們當前的體系結構很好匹配 - 它不會涉及太多的重寫，但仍應該導致更多可測試的代碼（另一個目標 - 我們目前沒有自動化測試）。

但我想知道，如果任何人有關於從DataSets移動到EntityFramework的一些提示/信息/文章。我認爲這對我們來說是最大的優勢，因爲它可以讓我們對數據進行建模並對其進行測試。不幸的是，我還沒能在網上找到關於這種遷移的任何信息。我們的數據庫設計非常好（謝天謝地），但是我們必須同時使用DataSet和EntityFramework一段時間，直到我們擺脫了DataSet - 我們不可能一次完成所有事情。

任何人都可以就此提供建議？

來源

2012-03-15 a_m0d

您是否繼續使用WebServices返回當前處於DataSet形式的數據？或者，您的應用程序是否會通過EntityFramework直接觸摸數據庫？ – 2012-03-15 19:07:20

@John我認爲我們仍然需要以某種方式使用Web服務。我們使用相同的Web服務來檢索Microsoft InfoPath中的數據，我們也無法擺脫它。 – 2012-03-15 19:12:00

這聽起來像你需要解決兩個單獨的問題。

如何使內部 Web服務（S）使用的EntityFramework 的。

其次，你如何將這些結果傳遞給Web服務以及如何傳遞這些結果。

對於＃1，我們只能猜測您當前實施的相關細節。但是，這可能是您可以搜索和尋求幫助的常見變化。

對於＃2，您可能想要定義一系列來回的業務對象。 Web服務可以在它們和EntityFramework對象之間進行轉換。（您大概可以直接傳遞EF對象，但根據您的場景，可能存在問題。）

來源

2012-03-15 19:25:37

我很好奇你指的是什麼「業務對象」。你的意思是序列化到XML/JSON，還是你指的是別的？ – 2012-03-16 11:36:30

@ a_m0d：「業務對象」只是具有屬性的類。他們的運輸方式（XML，JSON等）是一個完全獨立的問題。 – 2012-03-16 14:12:51

那麼Business Object與POCO類會有什麼不同呢？ – 2012-03-16 15:49:48

從數據集遷移到EntityFramework

回答

相關問題