我目前在一家使用ASP.NET Webforms和旧版ASP页面进行Web开发的公司工作。这对他们当前的项目非常有效,但我想说服/建议他们切换到ASP.NET MVC,因为他们的大多数代码库都包含将表单元素连接到存储过程参数。仅使用ORM也是可能的,但我认为利用这个机会切换到MVC框架是个好主意。
但是,我不确定在更新代码库时,在ASP.NET和Classic ASP代码中部署ASP.NET MVC应用程序会有多容易。 首先,我想问一下这是否可能。我见过关于使用经典ASP和ASP.NET MVC运行ASP.NET的线程,但不是所有三个都在同一个应用程序中。他们目前将Webforms和Classic ASP协同工作,因此与此相关的陷阱已经解决。 其次,有哪些强大的卖点可以帮助我说服团队其他成员从长远来看学习新框架和转换现有代码是否值得?
答案 0 :(得分:8)
我认为这是一个老问题,但由于我在同一条船上,我以为我会试一试。
在过去的12到15年里,我有一个用经典ASP编写的10万多页网站。与许多被黑客攻击的代码不同,它结构良好,复杂且高效,并且经过精心修改,以至于错误非常非常罕见。
过去三四年中添加的许多新功能都是在ASP.NET中实现的。这需要重新实现许多潜在的DAL和业务逻辑,当然,新的东西永远不会像近十年来一直运行的代码一样稳定。保持服务器的源关闭并远离窥探眼睛和手指也非常非常好。
我最初抵制MVC,但我爱上了它。它没有提供Webforms的所有功能 - 易于打包和可再发行的用户控件是我真正非常想念的 - 但它比我喜欢的Web开发更传统的应用程序开发。编写测试也更容易 - 对我来说是一个巨大的卖点。
因此,当前的Visual Studio解决方案如下所示:
IIS指向MVC项目文件夹,因此所有MVC内容都按预期工作。网站配置包括所有尚未迁移的ASP内容的虚拟文件夹(这将需要数年时间)。这些虚拟目录指向MVC文件夹结构之外的文件夹,其中存储了Webforms和Classic ASP代码/对象。当IIS收到请求时,映射到虚拟文件夹的内容将由经典ASP或webforms处理,而其他所有内容都将路由到相应的MVC区域。
我故意将这些项目分开;拥有ASP,MVC和webforms的单一解决方案都在相同的文件夹结构中是疯狂的可靠途径。
它运作良好,但在开始时配置有点痛苦。
所以,是的,所有这三种技术都会幸运地存在于同一个网站中,但是你面临着一些组织挑战。
答案 1 :(得分:1)
可以运行部分标准Asp.net以及Asp.net Mvc的站点。至于经典ASP,我从来没有这样做,但我想如果它与标准的Asp.NET一起运行,那么MVC将不会成为问题。
至于为什么,提醒他们经典ASP不是市场上理想的技能。有些人总会抵制变革和新技术(因为旧的东西工作正常,他们可能是对的)。找到渴望在技能组合中进行交易的开发人员,并让他们联合起来。但要确保MVC对应用程序有意义。管理层很可能想知道为什么当旧的东西工作正常时他们需要花大部分时间进行升级投资,这将是一个更难卖的。