c# - C# 和 Winforms 中正确的类实例化

Question

在过去两年担任 C#/WPF/MVVM 开发人员之后，我最近在一家新公司接手了一个 VB/Winform 项目。

我已成功将项目转换为 C#。我一直在做大量的研究，试图找出这个项目的最佳方法，但我试图弄清楚到底需要进行多少重构和重新配置。

我的问题是:之前的开发人员创建了两个巨大的静态类。有 30 多种表单可用于各种任务。每个表单都是从一个事件调用的，该事件由单击“主菜单”类型屏幕上的按钮驱动。当程序初始化时，调用来自这些大型类之一的函数来实例化每个表单。还有数量惊人的静力学和常量。

我已经分解常量并为它们创建了一个特定的类。我正在将大型类拼凑成更小、更易于管理(和责任特定)的类，但我有这个非常大的初始化函数来实例化所有这些形式。

因此，我的问题(最后)是:我在上面写的是资源噩梦吗？或者，这是我应该保留的某种正常的 VB/Winform 设计模式吗？我是否应该重写它以便在单击调用该表单的按钮时实例化每个表单/类，以便在关闭时可以将其处理掉？

感谢您给我的任何指导。如果我可以提供更多信息以使其更具体，请发表评论，我将进行编辑。

Answer 1

Is what I wrote above a resource nightmare?

是

Or, is this some sort of normal VB/Winform design pattern that I should keep?

绝对不是。该系统的设计在 VB 和 C# 中几乎相同。除了一些非常小的异常(exception)，语言之间的区别只是语法。

Should I re-write this so that each form/class is instantiated when the button calling that form is clicked, so it can disposed of when closed?

理论上是的。如果您使用 C# 编写，表单应该像它们一样运行。当然，如果原始开发人员非常喜欢全局状态，那么在表单的一次出现和下一次出现之间可能会潜伏着各种状态。

VB 的一些功能可能会使较弱的开发人员误入歧途。 Module(本质上是一个静态类，但有时更方便)的存在会引诱一些人添加比他们应该添加的更多的全局状态。同样在 VB 中，它会根据需要自动为每个表单创建一个与类同名的全局实例。这可能会导致开发人员将表单混淆为类和对象 - 导致表单的单个实例，而不是根据需要构建和处理。