在大型代码库中替换第三方Windows窗体UI控件

Question

我和我的同事正在调查如何通过我们的大型遗留代码库中的新UI控件替换第三方WinForms控件。实际上我们想要替换继承链中的第三方控件。通过继承第三方UI控件，第三方控件被用于数十个位置。我们希望尽可能安全地执行此更改，并在整个解决方案中进行最少的代码更改。你有经验如何开始？显然，继承意味着强耦合，所以我想在这里找到不那么痛苦的解决方案。

“抽象分支”概念是否适用于此？

Answer 1

这是一个非常主观的决定，基于您的团队对代码库和工作流程的理解。好的一面是你已经将所有控件子类化了，所以你已经完成了能够提供代码所需编译的任何属性的繁琐工作。

鉴于这是WinForms，这应该更直接，因为控件大小和位置是在Control级别设置的。您需要担心旧供应商控件中存在的属性/方法映射到新控件而不是表单布局。对于某些控件而言这可能是直截了当的，而对于其他控件则更复杂（即网格）。

最大障碍IMO将在InitializeComponent处理当前的设计时序列化逻辑。如果您已经创建了一个要从旧映射的属性 - ＆gt;新的，你必须要小心，当设计师在打开表单并修改某些内容后重新序列化所有内容时，你可能不希望序列化旧属性和新属性。举个例子：

旧供应商

this.myOldComponent.Data = this.dataSource;

新供应商

this.myNewComponent.DataSource = this.dataSource;

在这种情况下，您可以考虑在子类新组件上创建一个名为Data的新属性，以便旧代码可以正常工作而不会更改任何内容。假设您在设计中打开表单并将网格移动几个像素，从而导致设计人员序列化数据。你现在可能有：

this.myNewComponent.Data = this.dataSource;
this.myNewComponent.DataSource = this.dataSource;

您可以使用属性阻止序列化（在this SO question中对其进行了很好的讨论，但这只是您可能会遇到的一个示例。

我不认为这里有一个真正的模式，除非你的意思是源代码控制级别，在这种情况下我会说除了你的常规开发之外绝对创建一个新的branch;谁知道你可能遇到什么样的障碍，你想稍微搁置你的工作。

最终，你可能会认为最好是把它扯掉并撕掉旧组件并加入新组件，但如上所述，这是非常主观的。这种情况让我非常喜欢 WPF 和 MVVM 模型，因为您可以完全删除UI并保持业务逻辑不变。