在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所描述的，这两个改变是完全独立的 - 你可以做一个没有其他的。