在MVC 3 +實體框架中創建WebForms應用程序

Question

我有一個在ASP.NET 2.0 WebForms中開發的小型應用程序。爲了學習目的，我正在考慮將此應用程序轉換爲MVC 3 +實體框架。以下是模擬我的應用程序的最簡單示例。沒有什麼花哨。

應用程序佈局：

（圖像應爲 「輸入字段」，而不是 「文件」）

架構：

要點：

1. 的方法在服務層使用ADO.NET SqlCommandExecuteReader方法執行存儲過程

2. 大多數操縱等邏輯在存儲過程完成。幾乎沒有任何操作數據在服務層

現在我想將此應用程序轉換爲MVC。

問題：

1. 我可以得到什麼好處（技術上），如果我將這個應用到MVC +實體框架？

2. 我該怎麼辦？

3. 我看了一些基本的MVC3教程，但他們都談論EF代碼第一，我不認爲適合我的情況，因爲我想使用現有的存儲過程。那是對的嗎？

注：我想利用現有的存儲過程。假設我無法控制DB結構的變化。

更新1：

1. 沒有在我的應用程序單列直插式查詢。即使最小的查詢也是一個存儲過程。他們中的很多人。

2. 使用SQL Server，幾乎沒有改變任何其他DBS的機會。

更新2：

我的web表單的應用是完成了99％，並能去現場隨時但由於一些企業的障礙都沒有出現。同時，我想如果我可以轉換（即開發）這到MVC，我會學習，如果它能解決可以上線（我的第一個MVC），而不是webforms。

Answer 1

之前回答具體問題，我會指出你應該獨立的選擇爲2：

1. 轉換表示層，而不是使用的WebForms MVC。
2. 轉換數據層以使用EF而不是ADO.NET。

現在對於你的問題

MVC的

1. 優點包括在HTML更好的控制，更好的可測試性等EF的好處包括抽象掉DB-具體的東西（理論上可以與MySQL替代的SQL Server，假設一個合適的MySQL提供者），LINQ支持等。當然，這樣的轉換也有成本。
2. 分而治之。如前所述，您不必一次做所有事情。從表示層開始並將其轉換爲MVC。請記住，您可以混合使用WebForms和MVC應用程序，因此您不必同時轉換所有頁面。然後將您的數據層轉換爲EF。或者從相反的順序開始，無論您的項目是否合理。
3. [不是這個主題的專家]如果你嚴重依賴SP，那麼考慮傳統的EF。如果你只有幾個SP，那麼你可以先考慮代碼+使用DataSets處理SP（可能包裝在定製類中）以使所有的工作都可以工作，但這可能會變得複雜。與以前一樣，如果成本太高，則不必遷移到EF。

Answer 2

你有什麼好處？這是完全錯誤的問題。您應該問我現在的解決方案有哪些問題，以及如何通過用EF替換數據訪問或用ASP.NET MVC替換表示層來解決這些問題？

據我所知，你只是爲了學習的目的而這樣做 - 它沒有商業驅動力。在這種情況下，有一些點，這將讓你的一些想法：

• 如果你不想與普通EF方式，您將得到幾乎沒有好處，你不會學習EF替換現有SP的邏輯。 EF允許使用存儲過程來檢索映射實體或加載自定義類。映射實體通常代表數據庫中的視圖或表格 - 如果您甚至想要定義任何映射實體，則此處不清楚。加載自定義類時唯一的好處是自動填充結果集中的屬性。這意味着您將需要每個SP結果的類，這些結果的名稱與結果集中的列完全相同。 EF中的SP不支持多個結果集（默認情況下），也不支持自動加載關係。
• 當從ASP.NET Web Forms轉移到ASP.NET MVC + Razor時，您幾乎可以確定您的前端代碼不會在新解決方案中可用。您只需創建新項目，並從頭開始做前端工作。
• 正如@marcind所描述的，這兩個改變是完全獨立的 - 你可以做一個沒有其他的。