asp.net - 在 MVC 3 + Entity Framework 中创建 WebForms 应用程序

Question

我有一个在 ASP.NET 2.0 WebForms 中开发的小应用程序。出于学习目的，我正在考虑将此应用程序转换为 MVC 3 + Entity Framework 。下面是模拟我的应用程序的最简单示例。没有什么花哨。

应用布局:

(图像应为“输入字段”而不是"file")



架构:



关键点:

服务层中的方法使用 ADO.NET SqlCommand ExecuteReader执行存储过程的方法

大多数操作等逻辑是在存储过程中完成的。几乎没有对服务层中的数据进行任何操作

现在我想将此应用程序转换为 MVC。

问题:

如果我将此应用程序转换为 MVC + Entity Framework ，我会得到什么好处(技术上)？

我该怎么做？

我看过一些基本的 MVC3 教程，但它们都讨论了 EF 代码优先，我认为这不适合我的情况，因为我想使用现有的存储过程。那是对的吗？

注:我想使用现有的存储过程。假设我无法控制数据库结构的变化。

更新 1:

我的应用程序中没有一个内联查询。即使是最小的查询也是存储过程。成吨的。

使用 SQL Server 并且几乎没有机会更改为任何其他 DBS。

更新 2:

我的 webforms 应用程序已完成 99%，可以随时上线，但由于一些业务障碍，它没有上线。平均而言，我想如果我可以将它转换(即开发)到 MVC，我会学习，如果它可以上线(我的第一个 MVC)而不是 webforms 的。

Answer 1

在回答具体问题之前，我会指出您可能应该将选择分为 2 个:

将表示层转换为使用 MVC 而不是 WebForms。

将数据层转换为使用 EF 而不是 ADO.NET。

现在回答你的问题

MVC 的好处包括对 HTML 的更好控制、更好的可测试性等。EF 的好处包括抽象出特定于 DB 的东西(理论上你可以用 MySQL 替换 SQL Server，假设有合适的 MySQL 提供程序)、LINQ 支持等。当然还有这种过渡也需要成本。

分而治之。如前所述，您不必一次做所有事情。从表示层开始，将其转换为 MVC。请记住，您可以混合使用 WebForms 和 MVC 应用程序，因此您不必同时转换所有页面。然后将您的数据层转换为 EF。或者以相反的顺序开始，无论对您的项目有意义。

[不是该主题的专家] 如果您严重依赖 SP 而不是考虑传统的 EF。如果您只有几个 SP，那么您可以考虑先编写代码 + 使用 DataSet(可能包含在自定义构建的类中)处理 SP，以使一切正常，尽管这可能会变得复杂。和以前一样，如果成本太高，您不必转到 EF。