我正在开发一个winform应用程序，其中一组类及其方法从3d点计算几何。
由于算法中的步骤到步骤需要用户提供一些输入，我们设计了一些代表步骤的按钮。中间数据存储在类中（可能我们在将来的版本中使用结构），因此用户输入是。按下按钮的结果是，中间数据将被计算，保存并显示给用户，以便他可以编辑它，影响下一步的计算。
应用程序开始作为一个应用程序，它以4个步骤计算所有内容，但现在我们有超过10个步骤，因此我们将其分为3个部分（水平几何，垂直几何和其他......）。现在我正在进行一些划分，因为一切都变得过于复杂，无法在一个表单中管理所有gui交互，因此我将为表单的较小部分创建用户控件。
您对我有一般性建议吗？
我应该在我制作的控件中还是在一般形式中使用这些数据结构（输入和中间数据）？
答案 0 :(得分：2)
您应该避免将UI与业务逻辑混合在一起。通过这种方式，当程序变大时，维护起来会容易得多。它还可以使编写自动化单元测试变得更加简单。
如果您没有特殊原因使用winforms。我建议使用Windows Presentation Foundation（WPF）。阅读有关Model View ViewModel（MVVM）设计模式的教程。这是将UI逻辑与业务逻辑分离的一种非常好的方法。
从Winforms切换到WPF需要一些努力，但绝对值得。
编辑（回复评论）
这取决于你解决的问题。但一般来说：
在MVVM模式中：
模型将包含类/方法中的所有数据和算法。 ViewModel将连接模型中的所有内容并控制程序流，它将公开视图可以绑定的属性（命令，字符串，数字集合等......）。视图只是一个＆＃34;皮肤＆＃34;这使得用户可以与ViewModel进行通信。这是MVVM模式的一个非常简单的解释，我建议阅读有关它的教程。
第一次遇到这种模式时，它被称为模型视图控制器MVC，我喜欢AngularJS正在做什么，只需将其称为模型视图无论MVW因为有很多MV *。但是WPF专门为MVVM而构建。
最重要的是，如果您创建一个将要使用和维护多年的程序，那就是尽可能简化代码。而不是将所有功能写入Button_Click事件处理程序（我已经看到一些程序执行此操作），尝试为每个单独的任务编写一个类或方法（使用长描述性名称），这也称为Seperation of Concerns。换句话说，一个方法/类不应该执行多个任务。好消息是你最终得到了一个＆＃34;程序流控制器＆＃34; （ViewModel / Whatever）只是将数据从一个方法传递到下一个方法。只要查看你去的代码：啊哈，我确切地知道这里发生了什么！以同样的方式查看算法（模型）时，他们应该完成一项工作，所有变量都应该具有描述性名称。这使得其他开发人员很容易理解代码。
我根据类型划分命名空间也有很好的经验。所以每次你有多个某种对象（DataProviders，FileReaders等......）为它们创建一个命名空间/子命名空间并将它们放在那里。所以当你创建一个新的对象/接口/枚举时...你总是知道放在哪里。你总是知道在哪里找到它：哦它是一个DataProvider所以它必须位于ProjectName.Objects.DataProviders：）
所以我的建议是：有一些乐趣并阅读：MVVM和SoC
答案 1 :(得分：0)
可能state machine diagram会帮助您分散行动。在编码之前创建一些图表是一种更好的做法。