我不知道有任何公认的方法可以防止未维护的应用程序过时。
如果您想防止产品过时,则将其设计为可升级的。
至少在 .NET 中,您有很多很多的选项来创建可重用的组件:
单独的程序集,可以在任何 .NET 项目中使用,如果需要使用不同的技术,可以在以后扩展以支持 COM 互操作。
网页服务; 这些可以公开暴露并在几乎任何环境中使用。
接口和控制反转可用于支持可自由互换的组件,理论上这些组件可能来自甚至不是 .NET 的东西(只需构建一个 COM 包装器);
进程间通信——如果一切都失败了,你可以直接创建一个内存映射文件或命名管道,并开始从(或注定)一个全新的应用程序中汇集数据。
事实上,其中一些可能适用于您当前的 VB 项目。通常有无数不同的方法可以延长现有产品的使用寿命,同时逐渐将核心功能转变为新技术。
我不是 SOA 的铁杆,但这正是 SOA 试图解决的问题。我做了很多服务——事实上,这里几乎所有重要的东西都会在某个时候通过某种 Web 服务——而且我知道我可以随时完全删除一项服务并将其替换为不同的平台。它所要做的就是吐出 SOAP 或 JSON,我的 .NET 客户端仍然可以使用它。或者,如果我需要替换客户端,我可以直接连接到服务中已经存在的富域模型。
事实上,我已经这样做了——该架构曾经完全构建在 Delphi 7 平台之上。现在一切都在 .NET 3.5 上,从一个系统到另一个系统从来没有真正的硬切换。我们开始构建普通的 SOAP 服务,然后将很多应用程序内的业务逻辑转移到服务中,最终,当应用程序只不过是一个外壳时,我们用几个 .NET 客户端(有几个单独的应用程序),然后开始添加只能在较新平台上支持的各种安全功能和优化。等等等等。
因此,如果您提前计划,它绝对可以完成。当然,这里有很多人会建议不要提前计划,引用 YAGNI ……对于某些项目,也许这是真的。这完全取决于项目的成本/任务关键程度。如果产品需要使用 50 年,那么您可能需要考虑投资一些可靠的架构和设计,以便您轻松添加和删除子组件。