构建应用程序的“主要形式”理念的其他替代方案答案

【问题标题】：other alternative to the "Main Form" idea for structuring the application构建应用程序的“主要形式”理念的其他替代方案
【发布时间】：2013-08-21 20:37:29
【问题描述】：

我读过的关于 winform 应用程序的大多数问题都有一个表单类作为包含所有应用程序的主表单并使用此主表单调用 Application.Run

当主窗体中的代码开始增长时，窗体被划分为多个用户控件。

但这就是让我烦恼的地方。表单和用户控件应该只是 UI 控件，它们不应包含程序的任何逻辑。

但是“主窗体”的想法仍然有广泛的用途，可以处理从应用程序打开到应用程序关闭的应用程序生命周期。

为避免这种情况，我尝试在单独的静态“管理器”类中提供程序逻辑，这些类管理程序的不同部分，并使用主窗体管理它们。

例如，我有以下“ThemesManager”类

            public static class ThemesManager
            {
                public static void InstallTheme(string themefile) { }
                public static void ApplyTheme(Theme theme) { }
                public static void RemoveTheme(Theme theme) { }
                public static Theme[] GetThemes() { }
            }

在主窗体中

            public class MainForm
            {
                void InstallTheme_Click(object sender, EventArgs args)
                {
                // Call THeme.Install
                }

                void RemoveTheme_Click(object sender, EventArgs args)
                {
                // Call THeme.Remove
                }
            }

现在应用程序逻辑以某种方式分离，但我认为我正在破坏具有如此多静态类的应用程序架构，因为许多类都依赖于它们。例如，显示主题的用户控件使用 ThemesManager.GetThemes()。我觉得我这样失去了 OOP 的基本概念

那么我还有什么其他选择可以将逻辑与 UI 分开，并且没有“主窗体”作为应用程序的主要组件或控制器

【问题讨论】：

首先我想说，只有declarative style 可以帮助您在模型和视图分离的情况下进行编程，在winforms 中，您无法避免部分混淆模型和视图之间的代码。不过winforms中有些东西可以帮助你尽可能的分离模型和视图，比如使用event、delegate。在您的情况下，您可能希望将类 ThemesManager 定义为 instance class，在您的 MainForm 中初始化此类的一个实例，并在整个程序周期中使用该实例。
不确定 WinForms 但在 WPF 中有 APP.XAML 代码。
@KingKing ：是的，我们“避免部分混淆模型和视图之间的代码”。但问题在于将视图作为架构的中心部分。 UI 应该与其他组件松散耦合，以便轻松更改它，但我将这种方式视为主程序
@Blam：我不明白你的意思。你能解释一下吗？谢谢。
有一个名为MVP的设计模式通常用于winform。另一方面，我不推荐静态ThemesManager 类。相反，将其作为主窗体的实例。原因是为了确保并发安全和防止竞争条件。

标签： c# .net winforms architecture

【解决方案1】：

您可以使用以下设计模式：

模型-视图-演示者 (MVP)；
模型-视图-视图模型 (MVVM)；
模型-视图-控制器 (MVC)。

它们非常适合将逻辑层与用户界面层分开。你可以看到一些例子here。这个适用于 Model-View-ViewModel (MVVM)，适用于我。

设计模式的好处在于它们使您的代码可测试。

【讨论】：