尝试同时运行 WebForms 和 MVC3 时是否有任何需要注意的问题？
当前工作的代码库完全是 WebForms，大部分逻辑都被填充到代码隐藏文件中。我正在研究使用 MVC3 添加新页面和未来重构的可能性，而不必丢弃整个代码库（这是一个很大的禁忌）。所有这些页面都是同一个“应用程序”的一部分，因此它并不像使用 MVC 创建新项目那么简单 - 它们必须非常密切地交互，并且在某些情况下 WebForms 页面必须重定向到 MVC 页面，反之亦然。
我读过一些文章，展示了如何将两者集成（尽管是在非常简单的场景中，而我的场景相当复杂），但是有什么需要注意的问题吗？特别是从 WebForms 页面到 MVC 页面，然后返回 WebForms 页面，其中需要跨页面传递数据，例如从会话（并且不一定在加载时完全从数据库读取），例如工作流程如下：
- （WebForms）用户转到 CreateQuote.aspx?CustomerId=42 并输入一些数据。他们单击“处理”按钮...
- (MVC) /customers/42/process MVC 页面读取之前提交的信息，并执行一些额外的操作。用户单击“下一步”按钮...
- (WebForms) CompleteQuote.aspx?CustomerId=42&QuoteId=534235 页面，该页面从上一个 MVC 页面中提取信息并对其应用更多逻辑。
另外，我们现有的项目是一个 ASP.NET Web Site 项目（即每个单独的页面都是其自己的 DLL 的项目）；是否必须将其转换为 Web 应用程序 项目才能与 MVC 并存（由于代码隐藏文件中存在大量重复代码，仅此一项就需要进行重大重构工作）？
The current codebase at work is entirely WebForms, with most logic being stuffed into the code-behind file. I'm investigating the possibility of using MVC3 for new pages added and future refactoring without having to throw the entire codebase away (a big no-no). All of these pages are part of the same "application" so it's not as simple as just creating new projects with MVC - they have to interact very closely, and in some cases WebForms pages will have to redirect to MVC pages, and vice versa.
I've come across a few articles that show how it's possible to integrate the two (albeit in very simple scenarios, while my scenario is fairly complex), but are there any issues to be aware of? Specifically in regards to going from a WebForms page to an MVC page and then back to a WebForms page, where data is required to be passed across pages say from the Session (and not necessarily read entirely from a database upon load), for example a workflow like:
- (WebForms) User goes to CreateQuote.aspx?CustomerId=42 and enters some data. They click a "Process" button...
- (MVC) /customers/42/process MVC page that reads in the information submitted before, and does some extra things. User hits a "Next" button...
- (WebForms) CompleteQuote.aspx?CustomerId=42&QuoteId=534235 page that pulls out information from the previous MVC page and applies more logic to it.
Also, our existing project is an ASP.NET Web Site project (i.e. the one where every individual page is its own DLL); would it have to be converted to a Web Application project to exist side by side with MVC (that alone is a major refactoring effort due to large clumps of duplicate code across code-behind files)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我建议您避免在同一应用程序中混合 ASP.NET MVC 和经典 WebForms。将它们放在单独的项目中，并让它们通过标准 HTTP 协议机制（查询字符串参数、表单帖子、cookie...）进行通信。如果它们托管在同一域上，您可以在它们之间共享身份验证。您甚至可以在它们之间共享会话对象，即使它们是托管的在 IIS 中的单独应用程序池中（并不是说您应该使用会话，但这是另一个主题）。
就重用数据访问逻辑而言，根据现有 WebForms 应用程序的设计方式，您可以共享包含当前数据访问代码的程序集。如果您现有的应用程序设计不佳，不同层之间存在强耦合，那么您可以将此遗留代码包装在存储库后面，并且仍然至少重用数据库访问代码。
通过保持应用程序独立，您不需要引用某些旧代码来污染新的 ASP.NET MVC 应用程序，也不需要使用 ASP.NET 污染现有应用程序经典 WebForms 应用程序MVC 特定的东西。
I would recommend you to avoid mixing ASP.NET MVC and classic WebForms in the same application. Keep them in separate projects and make them communicate through standard HTTP protocol mechanisms (query string parameters, form posts, cookies, ...). You could share authentication between them if they are hosted on the same domain. You could even share session objects between them even if they are hosted in separate application pools in IIS (not that you should be using session at all, but that's another topic).
As far as reusing the data access logic is concerned, well, depending on how properly your existing WebForms application is designed, you could share the assembly that contains your current data access code. And if your existing application is poorly designed with strong coupling between the different layers, you could wrap this legacy code behind a repository and still reuse at least the database access code.
By keeping your applications separate you don't need to pollute your new ASP.NET MVC application with references to some legacy code and you don't need to pollute your existing application classic WebForms application with ASP.NET MVC specific things.