如何将现有的 ASP.NET 应用程序迁移到 ASP.NET MVC 模式格式
我想将现有 ASP.NET 应用程序迁移到 ASP.NET MVC 模式格式。 我应该遵循什么程序？ 任何分步说明都会非常有帮助。
I want to migrate an existing ASP.NET application to an ASP.NET MVC pattern format. What procedure should I follow? Any step-by-step instructions would be very helpful.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这是我的分步指南，基于我们公司从经典 ASP.Net Webforms 迁移到 ASP.Net MVC 期间所采取的步骤。 它并不完美，并且仍在进行中，因为由于站点的大小，我们必须分阶段进行此操作，但也许其他人会根据我们的结果找到并提交改进的答案。
阶段：
1. 规划 - 从 ASP.Net 中的 Web 窗体迁移到 MVC 需要仔细规划。 我们在行动中犯的错误是没有意识到这个阶段的规划实际上有两个方面，路线规划和模型/控制器/动作规划。
当您尝试扩展站点的功能或进行更复杂的迁移时，不这样做将会导致严重的问题。
尖端：
- 查看当前站点地图，并设计要在 ASP.Net MVC 应用程序中使用的改进站点地图/目录结构。 为您的网站找出一种“语言”，例如 ASP.Net MVC 的默认行为是使用 http://sitename/{controller}/{action}/{id} 行为，但是当您获得更多黑客路由规则的经验时，您可以覆盖此行为。
请记住，默认情况下每个控制器将通过应用程序的虚拟子目录路由到，例如 http://sitename/X 将路由到 XController（默认情况下其 Index 方法）， http://sitename/Y/Get 将路由到 YController 的 Get() 方法。 您可以根据需要更改此设置（路由非常强大），但这超出了本答案的范围。
使用现有的站点地图，指定当前每个 .aspx 页面应位于 MVC 结构中的哪个文件夹（当然，首先询问它是否应该存在）。
如果脚本、图像等没有存储在一起，或者存储在每个子目录内的某些“保留名称”文件夹中，请在重新设计时考虑立即这样做。
这是因为它允许您在 Global.aspx.cs 文件中使用 Map.IgnoreRoute() 路由规则命令来绕过将这些文件夹处理为路由，从而极大地简化您的设计。
在我们的例子中，我们镜像了当前站点的真实子目录布局，其中每个子目录成为一个控制器，例如/Account将有一个AccountController，/X将有XController。 所有位于其中的页面都被每个控制器中的操作所取代。 例如 http://sitename/profile/about.aspx 现在变成了 http://sitename/profile/about 并映射到 profileController 内的“about”ActionResult 方法。
这使我们能够通过一系列冲刺对一个或两个目录（或一个目录中的多个文件）进行部分迁移来保持敏捷性，而不必在更长的时间内一次性迁移整个站点。
在 Visual Studio 中创建新的 ASP.Net MVC 应用程序，并立即在 Global.asax 文件中创建规则，以忽略当前站点中存在的文件夹的路由规则。
将文件夹从 ASP.Net Web 应用程序复制到 ASP.Net MVC 应用程序文件夹。 运行网站并确保其正常工作（应该是这样，因为尚未使用路由规则）。
选择要迁移的子目录或子目录中的文件子集。
对于此子目录中的每个 .aspx 页面：
a. 首先创建它的视图。 我倾向于使用网页的网络浏览器呈现版本作为我的基本 HTML，然后将占位符放在我知道填充动态数据的位置。
b. 使用动态数据的占位符，使用简单的数据类型创建模型的初稿。 该模型一开始很简单，但随着您从原始站点迁移更多页面，会不断重构，因此如果它看起来有点沉重，请不要担心。 如果您发现一个模型中有太多符合您口味的属性，或者看到超出某些项目子集的模型的逻辑分组，也许这表明模型需要重构为拥有一个对象，而不是使用这些简单的数据类型作为属性，但在业务逻辑层中组成。
c. 如果尚未创建控制器，则创建控制器，并为您的计划已确定应路由到此视图的操作放置适当的 ActionResult 方法。
如果您意识到有一个新操作未映射到旧站点的页面，请为控制器创建视图，并包含适当的 //TODO: 标签，以便您可以跟踪此操作以在您之后实施已迁移现有页面。
d. 如果您的 global.asax.cs 文件中还没有 {*catchall} 路由规则，请考虑为未知操作添加一些处理代码。
e. 为模型创建构造函数类，以便给定控制器将具有的某些参数（作为您的 {id} 传入，或者可能是来自 URL 的 Request.QueryString 参数，或者 HTTP 标头或 cookie），模型将知道如何接触您现有的业务逻辑类并构建自身以供视图呈现。
f. 转至列表中的下一页，然后从步骤 a 重新开始。
最后创建路由规则，该规则将调用您的新控制器并允许实现您编写的操作。 调试、调试、调试...如果一切顺利，请删除从主站点迁移的现有文件夹和文件，以及 global.asax.cs 中的 IgnoreRoute 规则。
如果您希望保留旧目录和文件名以保持连续性（例如，用户可能已经在旧站点中的某些页面添加了书签），请以您喜欢的任何方式创建重定向。
以
注意：如果您在移植阶段保留 MVC 站点中旧子目录的确切名称，我意识到最好一次迁移整个子目录，因为只需执行几个文件即可更改您需要的路由规则write 变得更加复杂，因为如果存在与路由规则路径同名的现有文件夹，并且该文件夹具有 Default.aspx 文件，则 (/foldername/) 将默认为 Default.aspx 页面，因为它优先于路由规则。
提示：认真考虑使用 RouteDebug 等工具进行路由调试，以便您可以找出像上面这样的奇怪的事情，或者当您有多个路由规则触发并导致意外行为时。
这是我的初稿，如果我错过了任何步骤或者您在指南中发现任何漏洞，请给我反馈，我会适当修改答案。
These is my step-by-step guide, based on steps we have taken at my company during our move from a classic ASP.Net Webforms to ASP.Net MVC. It's not perfect, and still ongoing since we have to do this in stages because of the size of the site, but perhaps someone else will find and file an improved answer based on our results.
Stages:
1. Planning - moving to MVC from Web Forms in ASP.Net requires some careful planning. The mistake we made in our move is not realising that there are are really two aspects to this stage of planning, route planning and model/controller/action planning.
Not doing this will cause serious issues later on as you try to extend functionality of your site or hit more complex migrations.
Tips:
- Look at your current sitemap, and design the improved sitemap/directory structure to be used in the ASP.Net MVC application. Figure out a 'language' for your website, e.g. the default behaviour of ASP.Net MVC is to have a http://sitename/{controller}/{action}/{id} behavior, but you can override this as you gain more experience hacking routing rules.
Remember by default each Controller will be routed to via a virtual subdirectory of your application, e.g. http://sitename/X would route to XController (and by default its Index method), http://sitename/Y/Get would route to YController's Get() method. You can change this as you please (routing's really powerful), but that's beyond the scope of this answer.
Using the existing sitemap, specify what folder in the MVC structure each current .aspx page should fall (of course, first ask if it should exist at all).
If Scripts, Images etc are not stored together, or in some 'reserved name' folders within each subdirectory, consider doing so now as you're redesigning.
This is as it would greatly simplify your design by allowing you to use a Map.IgnoreRoute() routing rule command in the Global.aspx.cs file to bypass processing these folders as routes.
In our case we mirrored the real subdirectory layout of the current site, where each subdirectory became a controller, e.g. /Account would have an AccountController, /X would have XController. All pages that fell inside there were replaced by actions within each Controller. e.g. http://sitename/profile/about.aspx now became http://sitename/profile/about and mapped to the "about" ActionResult method inside the profileController.
This is allowing us to stay agile by doing a partial migration of one or two directories (or several files inside one directory) over a series of sprints, rather than having to migrate the entire site in one go over a much longer duration.
Create a new ASP.Net MVC application in Visual Studio and immediately create the rules in the Global.asax file that ignore routing rules for the folders that exist in the current site.
Copy the folders from the ASP.Net Web Application to the ASP.Net MVC Application folders. Run the website and ensure it works properly (it should as no routing rules are being used yet).
Pick a subdirectory or subset of files within a subdirectory to migrate.
For each .aspx page inside this subdirectory:
a. Create its View first. I tend to use the web-browser rendered version of the page as my base HTML, and then put placeholders in the locations that I know are filled with dynamic data.
b. Using the placeholders for the dynamic data, create a first-draft of the Model using simple data types. This model will start off simple, but be constantly refactored as you migrate more pages from the original site, so don't worry if it starts looking a little heavy. If you find yourself with too many Properties in one Model for your taste, or see a logical grouping beyond just the Model of certain subset of items, perhaps this is a sign the Model needs to be refactored to have an object instead with these simple data types as properties but is composed in the business logic layer.
c. Create the controller if it hasnt been created yet, and put the appropriate ActionResult method for the Action your planning has determined should route to this view.
If you realise something that there is a new action that doesn't map to a page from the old site, then create the View for the controller, and include appropriate //TODO: tags so you can keep track of this to implement after you have migrated the existing pages.
d. Consider putting in some handling code for unknown actions as well, if you don't have a {*catchall} Routing rule for this already in your global.asax.cs file.
e. Create the constructor classes for the Model so that given certain parameters that the Controller will have (passed in as your {id} or possibly a Request.QueryString parameter from the URL, or an HTTP header or cookie), the Model will know how to reach out to your existing business logic classes and build up itself for rendering by the View.
f. Go to next page in the list and start again from step a.
Finally create the routing rule that will call your new Controller and allow the Actions you have written to be implemented. Debug, debug, debug...Once you're happy all is well, remove the existing folder and files you've migrated from your main site, as well as the IgnoreRoute rule in the global.asax.cs.
Create a redirect in whatever manner you prefer if you wish to preserve old directory and file names for continuity (e.g. users may have bookmarked certain pages in the old site already).
Note: If you are keeping the exact names of the old subdirectories in your MVC site during the porting phase, it's preferable to migrate a whole subdirectory at a time I've realised, because by only doing a few files the routing rules you need to write become more complex since if an existing folder exists with the same name as a routing rule's path and that folder has a Default.aspx file then (/foldername/) will default to the Default.aspx page, as it takes precidence over the routing rules.
Tip: Seriously consider using a tool like RouteDebug for route debugging so you can figure out strange things like above, or when you have multiple routing rules firing and causing unexpected behaviors.
This is my first draft, please give me feedback if I've missed any steps or if you see any holes in the guide, and I'll modify the answer appropriately.
这些额外的提示可能有助于
使用 @RenderSection("Footer",false) 代替 @section footer { } 等等，如果您除了 View 中的主体之外，还有任何其他 ContentPlaceHolder，其中 RenderBody() 。
所有旧的正常 runat="server" 标记都是无害的，不会阻止编译，并且可以在之后清除
所有控件可见性，可以在代码隐藏和标记中轻松控制可见性（Visible =“True”），并通过使用在code_behind中进行控制控件 ID 必须重构为 Razor 视图中的 ViewBag Collection 和 @if 块。
您还可以围绕此观看 Pluralsight 的精彩课程
主题（3小时49分钟）
May these few additional tips will assist
use @RenderSection("Footer",false) for @section footer { } and so on,if you have any additional ContentPlaceHolder except the main body in View which RenderBody() .
all the old normal runat="server" tags are harmless and do not prevent compile and can be cleaned afterwards
all controls Visibility which was easily controlled in code behind and markup (Visible="True") and controlled in code_behind by use of Control Id must be refactored to ViewBag Collection and @if blocks in Razor view.
you can also watch this excellent course of Pluralsight around this
topic (3h 49m)
我不认为存在从 ASP.NET WebForms 到 ASP.NET MVC 的“逐步迁移”这样的事情。 它们是建立在同一框架上的两种完全不同的设计模式，但是（在大多数情况下）有很多东西不仅需要移动，而且需要完全重新设计，如果您不仅仅是想构建一个网络MVC 模板项目而不是 WebForms 模板上的应用程序。
主要原因是关注点分离，MVC 中的关注点分离比 WebForms 中的要严格得多。 我目前正在（好吧，我应该……）将一个旧的且有很多问题的业余爱好项目从 WebForms 迁移到 MVC，我的方法基本上是“查看功能，从头开始重新构建它”。 当然，我有一些用于格式化输出等的辅助方法，我刚刚将其包含在我的新项目中，但我选择的大多数基本内容只是完全重做。 您可能会惊讶地发现，我现在用 MVC 实现了一年半前为 WebForms 应用程序设置的相同目标 - 使用实体框架、jQuery 和其他甜蜜的东西，您将能够在几个小时内得出结果。
I don't think there is such a thing as a "step-by-step migration" from ASP.NET WebForms to ASP.NET MVC. They are two completely different design patterns built on the same framework, but there are (in most cases) a lot of things that need not only to be moved, but completely re-designed, if you don't just want to build a web app on the MVC template project instead of the WebForms template.
The main reason for this is the separation of concerns, which is much stricter in MVC than in WebForms. I am currently working (well, I should be...) on migrating an old and pretty buggy hobby-project from WebForms to MVC and my approach has basically been "look at the functionality, re-build it from scratch." Of course I had some helper methods for formatting output etc that I just included in my new project, but most of the basic stuff I chose just to redo completely. You'd be surprised how little it takes me to reach the same goals with MVC now, that I set up for the WebForms app a year-and-a-half ago - with the use of Entity Framework, jQuery and other sweet stuff, you'll be able to produce results within a couple of hours.
我的回答是“你不会”:)。 如果您确实想这样做，您可以使用当前的 asp.net 站点作为您的最终目标，或作为需求“文档”。 也许您可以在模型中使用数据层，但您必须重新设计整个站点。
正如 Tomas 已经指出的那样，它与经典的 ASP.NET 非常不同。
My answer would be "You don't" :). If you really want to do this, you can use the current asp.net site as your end goal, or as a requirements 'document'. And maybe you can use the datalayer in your model, but you'll have to redesign the whole site.
As Tomas already pointed out, it's VERY different from classic asp.net.