选择：从经典 ASP 迁移到 .NET 或迁移到开源平台
我的组织手上有很多遗留的 ASP 软件。
由于我们认为微软明显缺乏对其旧产品的支持，因此我们需要弄清楚下一步要迁移到什么。
如果我们从经典 ASP 迁移到 ASP.NET，感觉就像是一次“完全重写”“迁移”。 由于情况可能如此，我们正在考虑转向免费（如啤酒和语音）平台。 我特别认为我们的投资（我的意思是编程工作）最好花在一个能让我们不断发展的平台上，而不是强迫我们每四到五年就转储一行代码。 这是我们一直用来提倡走向“免费”平台的主要论点。
目前，我们正在考虑将 Java 与 JRuby 或 Groovy 等动态语言混合使用。
我的问题是：什么是好的迁移选择？ 我们的恐惧是没有根据的吗？ 无论如何，我们（可以想象）是否需要在 4 或 5 年后重写大部分代码库？ 对于迁移到 .NET 或免费平台，您有何看法？
My organization has a lot of legacy ASP software on its hands.
Since our perception is that Microsoft has shown a distinct lack of support for its older products, we need to figure out what to migrate to next.
If we migrate to ASP.NET from Classic ASP, It feels like that'd be a 'complete rewrite' "migration". Since that is probably the case, we're thinking about turning to a free (as in beer and as in speech) platform. I particularly think our investment (in programming effort, I mean) would be better spent with a platform that will let us evolve, rather than forcing us to dump very single line of code every 4 / 5 years. This is the main argument we've been using to advocate moving towards a 'free' platform.
Currently we're thinking about using a mixture of Java with a dynamic language like JRuby or Groovy.
My questions are: What would be a good migration choice? Are our fears unfounded? Would we (conceivably) need to rewrite a large portion of the codebase after 4 or 5 years anyway? What arguments do you have for moving to either .NET or to a free platform?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我们最近将一个重要的 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 风格而不是选择完全重新开发）可能并不适合所有人 - 但它确实为您提供了一个低影响的 ASP.NET 入口点，然后允许您在此基础上进行构建打好基础，同时充分利用现有的代码库和技能。
We recently migrated a substantial ASP project to ASP.NET and it's definitely possible to do a migration that doesn't become a complete rewrite, preserving a susbstantial proportion of the original code (although we benefited from some fairly well architected code with good separation between the business logic and the presentation layers from the outset).
We looked at two possible routes to the migration:
A ground-up rewrite as a 'proper' ASP.NET application making the most of the built-in controls and shifting all of the business and data access layers into classes etc - ie the way we approach a new ASP.NET project.
A more basic syntactic migration, taking the ASP pages and changing them over to ASP.NET without making too many up-front changes to the structure or logic. Then building on that as we continue to develop the site by making better use of ASP.NET controls, separate classes etc for new and revised functionality.
Due to schedule pressures, we adopted the second route, allowing us to make the switch sooner rather than later and then take a longer-term view on more fundamental changes as part of future developments.
On that basis, for the initial migration we were able to re-use the majority of the existing code, although this is gradually being replaced as we go forward. With an 'average' page having, say, 50-200 lines of HTML and 50-500 lines of VBScript code (as separate functions, not mixed into the HTML spaghetti-style), we found it took about an hour per page to migrate them, including changing all of the ADO data access to a new ADO.NET data access layer. Some simple pages took just a few minutes - some of the more complex pages took a whole day - but about an hour a page was the overall figure across hundreds of pages, with the time to change the data access representing a significant part of the effort.
If we were to redo the migration today, we'd use ASP.NET MVC rather than web forms as it maps better to the way that the original pages were written - although I couldn't comment on whether or not a migration to MVC would take more or less time.
This doesn't necessarily have any bearing on whether or not you want to move to a free platform or change languages - you might have other reasons for wanting to do this. (Our client was Windows based so moving to ASP.NET, development time aside, carried no additional costs.) However, I can say that it's possible to migrate a substantial ASP site to ASP.NET without a complete rewrite - and it's equally possible to migrate from earlier versions of ASP.NET to more recent versions with minimal work. Obviously the route that we chose, preserving some of the ASP feel to the code rather than opting for a complete redevelopment, might not suit everyone - but it does give you a low impact entry point into ASP.NET that then allows you to build on that groundwork while making the most of your existing codebase and skills.
你知道 mono 存在吗？
我认为您会发现一种语言的寿命并不像您想象的那么重要，因为应用程序的主要版本的寿命很可能比大多数语言的寿命要短。 公平地说，.NET 2.0 -> 3.0 是一个相当小的转变，而不是“转储每一行代码”的练习。 如果您甚至想升职，这还不是真正需要的。
我认为对于您可能考虑的任何给定平台都可以提出强有力的理由，我会考虑其他因素，例如程序员的舒适度/技能/熟悉度、社区支持、扩展和目的适应性。
You know mono exists right?
I think you'll find that the longevity of a language is not as important as you think it is, since the lifetime of the major versions of an app is really quite likely to be less than that of most languages. And to be fair to .NET 2.0 -> 3.0 is a pretty small shift up, not a "dumping every single line of code" exercise. If you even wanted to shift up, which isn't really required yet.
I think a strong case could be made for any given platform you might consider, I'd look at other factors like your programmers comfort/skills/familiarity, community support, extensions, and fitness for purpose.
选择取决于您的公司是否有能力支持您的选择。
您要自己支持该代码吗？ 如果是这样，您现在的技能基础是什么？
如果您目前正在使用 ASP，那么 ASP.NET（是否重写代码）似乎是第一个尝试的想法，即使您没有意识到，通过迄今为止使用 ASP，您可能已经获得了以下方面的大量知识：维护 IIS 以及大量基于 Microsoft 的服务和服务器，您可以在 ASP.NET 开发、部署和支持中重用或至少轻松适应它们。
JAVA、RUBY，无论您选择什么，任何技术的美观/有用/强大/可用性/耐用性都取决于其维护人员。
您应该提出的问题是：
..等等..
不要因到处的成本或免费与非免费而分散自己的注意力。
当项目背后的人员对技术未知/陌生时，支持的工时可能比大多数为您提供支持的打包软件解决方案要昂贵得多。
对于开发环境也是如此，您必须为 IDE/服务器等支付更多费用，但最终您需要经历的学习曲线较少，并且在您的专业水平上获得支持。
此外：就像 @annakata 所说，您有很多机会/项目来实现“像啤酒一样免费”的 ASP.NET 功能。无论是否是单声道。
示例：如果您愿意，您可以使用 Apache 设置 ASP.NET 服务诸如此类的事情..
根据您所知道的和您想知道的来选择您想要采用的技术，而不是您认为最新和最流行的技术，特别是如果您甚至开始考虑重建代码集的全部原因这是由于微软缺乏对ASP的支持。
The choice lies in your company's ability to support whatever you choose.
Are you going to support the code yourselves? If so, what is your skill set base right now?
If you are currently enjoying ASP, ASP.NET (code rewrite or no) seems like the first idea to try, even if you don't realise it, by having used ASP thus far, you have probably acquired a great deal of knowledge in maintaining IIS, as well as the plethora of Microsoft based Services and Servers that you can reuse or at least easily adapt to, in ASP.NET development, deployment and support.
JAVA, RUBY, Whatever you choose, the beauty/usefulness/power/usability/durability of any technology lies on the people behind its maintenance.
The questions you should be making are:
..and so on..
Don't distract yourselves with costs here and there or free versus non free.
when the technology is unknown/new to the people behind a project, man hours in support can be much more expensive than most packaged software solutions out there, which will then provide you with support.
This is also true for development environments where you have to pay more for the IDE/Server/etc, but on the bottom line you have less of a learning curve to go through and support at your level of expertise.
Besides: just like @annakata said, you have plenty of opportunities/projects to implement "free as in beer" ASP.NET functionality.. mono or not..
Example: you can set up ASP.NET service with Apache if you like that sort of thing..
Choose what technology you want to adopt by what you know and what you want to know, not what you think is the latest and greatest in buzz, specially if the whole reason why you even started thinking about rebuilding your code set is due to the lack of support for ASP from Microsoft.
鉴于行业不断变化，工具、平台和语言不断发展以最大限度地提高效率，我认为您无法摆脱每 4-5 年迁移一次的痛苦。 无法保证 Groovy/Ruby/C# 不会发生变化以采用下一个重大技术。
就我个人而言，我不会为了 100% 的未来证明自己而失眠。 如果这是目标，那么您不妨使用汇编，即使如此，也不能保证它会保持不变。
只需考虑以下几点
1）你们知道什么？ 如果他们是 VB 人员，那么转向 VB.NET 是有意义的
2）您对工具有多少预算？
3）您想要迁移的平台是否有您需要的东西？ 我记得有一段时间我惊讶地发现 Powerbuilder 对正则表达式的支持（或缺乏）
4）平台周围有社区吗？
I don't think you can escape the pain of migrating every 4-5 years given that the industry is in a continuous flux and tools, platforms and languages evolve to maximize efficiency. There's no guarantee that Groovy/Ruby/C# won't change to adopt the next big thing.
Personally I wouldn't lose sleep trying to 100% future proof myself. If that is the goal then you might as well use assembly and even then there's no guarantee that'll stay constant either.
Just consider the following
1) What do your guys know? If they are vb guys it makes sense to move to VB.NET
2) What budget do you have for tools?
3) Does the platform you want to move to have the stuff that you need? I remember some time back discovering with amazement Powerbuilder's support (or lack thereof) for regular expressions
4) Is there a community around the platform?