在C#和Winforms中进行适当的类实例化

Question

在最近两年担任C#/ WPF/MVVM开发人员后,我最近在一家新公司接管了一个VB/Winform项目.

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

我的问题是:前一个开发人员创建了两个巨大的静态类.有30多种形式用于各种任务.每个表单都是通过点击"主菜单"类型的屏幕上的按钮驱动的事件来调用的.当程序初始化时,调用来自这些超类之一的函数来实例化每个表单.还有一些令人难以置信的静力学和常数.

我已经打破常量并为它们创建了一个特定的类.我正在将大型类拼凑成更小,更易于管理(和特定于职责)的类,但我已经拥有了这个非常大的初始化函数,可以实例化所有这些形式.

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

感谢您给我任何方向.如果我可以提供更多信息以使其更具体,请发表评论,我将进行编辑.

Answer 1

我上面写的内容是资源噩梦吗？

是的

或者，这是我应该保留的某种正常的 VB/Winform 设计模式吗？

绝对不。VB 和 C# 系统的设计几乎相同。除了一些非常小的例外，这些语言之间的差异只是语法。

我是否应该重写此代码，以便在单击调用该表单的按钮时实例化每个表单/类，以便在关闭时可以将其丢弃？

理论上是的。这些表单的操作方式应该与使用 C# 编写时的操作方式相同。当然，如果最初的开发人员非常喜欢全局状态，那么表单的一次外观与下一次外观之间可能潜伏着各种状态。

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