我的组织拥有大量遗留的ASP软件.
由于我们认为微软已经显示出对其旧产品的明显缺乏支持,我们需要弄清楚要迁移到下一个产品的内容.
如果我们从Classic ASP迁移到ASP.NET,感觉就像是'完全重写'"迁移".由于情况可能就是这样,我们正在考虑转向免费(如在啤酒和言论中)平台.我特别认为我们的投资(在编程方面,我的意思是)会更好地用于让我们发展的平台,而不是强迫我们每4/5年转储一行代码.这是我们一直用来倡导走向"自由"平台的主要论点.
目前我们正在考虑将Java与动态语言(如JRuby或Groovy)混合使用.
我的问题是:什么是一个很好的迁移选择？我们的恐惧没有根据吗？我们(可以想象)是否需要在4或5年后重写大部分代码库？你有什么理由转向.NET或免费平台？
我们最近将一个实质性的ASP项目迁移到了ASP.NET,它绝对有可能进行一次不会完全重写的迁移,保留了原始代码的大部分(虽然我们从一些相当好的架构代码中获益,但是它们之间有很好的分离.业务逻辑和表示层从一开始).
我们查看了两种可能的迁移路径:
作为一个"适当的"ASP.NET应用程序进行全面重写,充分利用内置控件并将所有业务和数据访问层转换为类等 - 即我们处理新ASP.NET项目的方式.
一个更基本的语法迁移,将ASP页面更改为ASP.NET,而不对结构或逻辑进行太多的前期更改.然后在我们继续开发网站的基础上,通过更好地使用ASP.NET控件,单独的类等来获得新功能和修订功能.
由于进度压力,我们采用了第二条路线,允许我们尽早而不是更晚地进行转换,然后对未来发展的更多根本性变化采取长期观点.
在此基础上,对于初始迁移,我们能够重用大部分现有代码,尽管随着我们的发展,这逐渐被替换.有一个"普通"页面,比如50-200行HTML和50-500行VBScript代码(作为单独的函数,没有混合到HTML意大利面条样式),我们发现每页需要大约一个小时才能迁移它们,包括将所有ADO数据访问更改为新的ADO.NET数据访问层.一些简单的页面只花了几分钟 - 一些更复杂的页面花了一整天 - 但是大约一个小时的页面就是数百页的总体数字,而改变数据访问的时间代表了工作的重要部分.
如果我们今天重做迁移,我们将使用ASP.NET MVC而不是Web表单,因为它更好地映射到原始页面的编写方式 - 尽管我无法评论是否迁移到MVC花费更多或更少的时间.
这不一定与您是否想要迁移到免费平台或更改语言有关 - 您可能有其他原因想要这样做.(我们的客户端是基于Windows的,所以转向ASP.NET,开发时间放在一边,不需要额外的成本.)但是,我可以说,有可能将一个实质性的ASP站点迁移到ASP.NET而不需要完全重写 - 而且同样可能从早期版本的ASP.NET迁移到最新版本,只需要很少的工作.显然,我们选择的路线,保留代码的一些ASP感觉,而不是选择完全重新开发,可能并不适合所有人 - 但它确实为您提供了一个低影响力的入口点,然后允许您构建在充分利用现有代码库和技能的同时进行基础工作.
京公网安备 11010802040832号 | 京ICP备19059560号-6 