什么是好的MFC++；用于多个类似窗口排列的GUI体系结构

我正在考虑重写十多年前编写的MFC对话应用程序。我最初选择了对话框应用程序类型，因为一般来说，用户单击控制输入，应用程序通过USB从硬件提供实时数据，并在编辑框中显示数据。该应用程序还将信息写入文件。由于用户从不进行任何文件编辑，我认为不需要SDI或MDI应用程序类型

现在，我了解到SDI应用程序类型与CFormView一起提供了一些有趣的优势，如滚动、窗口大小调整：

我重写的原因是我的应用程序不可维护，扩展性不好。最初，我为我显示的每种类型的“屏幕”创建了一个CDialog，但在各种屏幕中有许多代码是通用的。事实上，随着时间的推移，我开始重用CDialog类，并使用状态变量简单地隐藏、重命名或重新定位许多控件，以使屏幕在应用程序上下文中看起来合适

我试着从一个公共基类派生CDialog类，但这样并没有实现很好的代码重用。我还发现我有一些常用的资源，我经常将这些资源传递给各个窗口，这只会增加不必要的开销

随着应用程序的发展，也很难跟踪应用程序的状态（用于处理USB硬件数据输入、用户输入、按钮启用等）。使用分层状态图作为我的应用程序的基础可能会解决这个问题

是否应该考虑在一个cFabVIEW上设置所有必要控件的超集，并从一开始就简单地隐藏、重命名和重新定位控件，并使用状态图来管理这一点？

我看到的所有示例都将代码直接放在输入控制处理程序中，但也许我应该使用这些处理程序来更改状态，然后让状态机进行决策，以减少这段意式代码

所以我的主要问题是：
1.如果用户不执行编辑，SDI会为我购买任何用于写入和读取文件（如报告和日志记录）的东西吗？
2.CFormView有意义吗？
3.将所有控件放在一个CFormView而不是多个类和对话框资源上有意义吗？
4.您是否尝试过在MFC中使用状态机，如Boost Statechart或Miro Samek的Quantum Leaps

---

重写很难有好的结局，尤其是当作者不熟悉指定的框架时（例如，滚动视图与应用程序类型无关）。正确构建应用程序才有帮助。拿一张纸记录当前状态，设计一个提议的架构。UML是有帮助的，但不是绝对必要的。不要触碰代码，直到你对事情的发展有了清晰的认识。从你的问题来看，你甚至对你的应用程序试图解决的问题没有一个清晰的理解。我同意理解和记录项目需求的重要性。我编写并维护了这个应用程序，14年来它在我的客户中非常成功。除了编写软件，我在公司还有其他职责，所以很遗憾，随着项目的发展和功能的增加，我没有时间进行重构。事后发现改进的机会往往更容易。我希望一些有经验的MFC开发人员能对我的问题提供一些见解。CFormView看起来确实比使用CDialog更容易滚动（在需要的地方）。