Windows 窗体设计器和对旧代码重构项目的影响

Question

所以—— 我正在开发一个 1.5M+ 行的大型代码库 UI 是使用 Windows 窗体设计器创建的 该应用程序当前是桌面应用程序 我正在尝试将应用程序重建为网络应用程序 我找到了一个可以解决问题的技术堆栈 该堆栈包括一个 .Net 后端、一个 DOJO UI 和一个 MS MVC 架构

问题 - 在查看了可用于这种转换的各种产品之后，我们还没有发现任何看起来很合适的产品 从头开始编写所有内容 - 即使只是 UI 也是不可行的

事物的状态 - 从业务角度来看，一次性完成此操作的大爆炸式解决方案有两个风险 我们提出的技术堆栈已经过很好的审查，虽然我们还没有结婚，但现在需要一些说服力才能让我们放弃

我们目前的做法 - 我们正在考虑尝试构建一个自定义工具，将 Windows 窗体设计器生成的代码转换为使用 DOJO 库而不是 MS 原生东西生成的等效 UI——主要是因为 MVC 似乎太不成熟

问题—— 我们如何在程序上解析 Windows 窗体设计器输出，以便我们可以遍历给定显示中存在的 UI 元素，以便我们可以识别它们并从我们选择的目标库中选择类似的元素。

我认为这个问题与“是否有允许以编程方式解析 Windows 窗体设计器输出的 SDK？”的问题相同

我从高层次上查看了 VS Studio SDK，并确信这是错误的答案，但我可能弄错了。请告知 - 问候。

所以必须这样做的原因是因为当前的部署模式非常昂贵。我无法详细说明细节，因为这都是专有的，但简而言之 - 当前状态的应用程序必须部署在 Citrix 上，服务器成本在每月 10k 范围内运行。这是这样做的重大经济动机。我也知道重写的成本通常在 4 美元/LOC 范围内……这将非常昂贵——比如 400 万美元。这也已经完成，所以问题归结为 - 在考虑劳动力成本的同时，我怎样才能做到最便宜。使用网络服务器提供应用程序预计可将所需的服务器数量减少大约 95%。当前负载所体验到的性能已经在推动合同 QOS 要求。

不这样做是一种逃避——这确实需要发生，尽管以这种方式处理问题可能不是正确的方法。还有其他建议吗？

Answer 1

如果您的问题需要进行大量更改，您可以考虑使用自动更改工具，例如 program transformation 系统 (PTS)。此类工具提供了为任意语言（和/或 WFD 等异常工件）定义解析器的方法，并对代码进行可靠的更改。

它们旨在解决 4 美元/行的手动代码转换成本（实际上比这更高），以及每天 200 行（比 Gartner 引用的每天 140 行手动转换更大）的相关问题，完成这项工作需要 25 个人年。

PTS 需要相当大小的代码库才能实现规模经济，但您似乎拥有这一点。他们解决了通常被认为难以手工完成的问题。

我不确定他们是否会按照你的描述完成这项工作，但你应该看看。

披露：我是其中一种工具的提供者。