C# 跨类/控件调用-传递引用、使用事件或更改结构

我有一个长期运行的后台工作控件，它是我的主窗体的一部分。到目前为止，这个工人的方法还没有太多的工作要做。但是，在worker方法中添加了一些新特性和一些更好的错误检测，这意味着它现在有点膨胀，许多方法都是从worker方法中提取出来的

后台工作人员的主要工作是在面板控件中加载和显示的用户控件的多个实例上执行方法。后台工作程序和所有用户控件都是主窗体的子控件。由于后台工作程序现在变得相当大，我认为是时候将后台工作程序（或至少是方法）提取到它自己的类中，以使将来的更改更容易，提高可读性并简化后台工作程序方法之间的数据访问

我的问题是，我应该如何根据用户控件和主窗体构造新类

我的想法是

• 在后台工作程序开始时，将用户控件的所有引用传入新类。这将像以前一样维护父子兄弟关系，但我不知道将UI元素引用传递到非UI类中是否是个坏主意。也不是很抽象
• 使用新类中的事件让主窗体执行用户控件中的方法。这让人觉得凌乱、不必要，而且很容易被打破。这将是抽象的
• 如何使新类成为用户控件所有实例的父类。我觉得主窗体应该是用户控件的父控件，因为它们都是UI元素，而新类将没有UI元素。虽然我觉得这提供了更好的结构，但抽象性更少（见下文）

我认为我正在与程序层次结构的UI和功能作斗争。控件的显示是否比功能更重要？我觉得这个函数应该尽可能地从UI中抽象出来，UI实际上只是一种在命令行程序中设置参数的奇特方式。我还认为抽象是我目前的流行哲学（我通过微控制器学习编程，在微控制器中抽象没有那么重要）

---

这是漫长的一天，我不确定这是否有意义。请随时纠正我，我会尽力澄清任何令人困惑的问题。提前感谢。

我将使用您的第一种方法，并将对象传递给您的新类。这在很大程度上适用于依赖项注入的建议：

所有用户控件都在dowork（）中更新？我的意思是，用户控件是立即更新还是（在某些事件中）随机频繁地更新用户控件？第一种方法更容易实现。第二种方法更易于单元测试。@AseemGautam用户控件是通过串行（Modbus）连接的真实设备的表示。后台工作程序调用用户控件，用户控件将命令从串行端口发送到设备。用户控件UI元素随设备的响应（例如温度）而更新。由于Modbus是半双工的，因此对用户控件的调用是按顺序进行的，因此不会一次全部更新。后台工作程序运行起来像。。。等待条件合适，呼叫第一个机组，呼叫第二个机组。。。设置新的条件，冲洗，重复。@Ginosaji我同意。我认为我的问题的一部分是权衡什么更有价值。Kai Hartmann的参考文献确实展示了一种相当轻松的单元测试方法。谢谢你的回答和链接。很多编程实践都超出了我在低级C编程方面的经验范围，我总觉得自己在迎头赶上。我只是又赶上了一点。：）