.net 紧凑框架最佳实践：构建GUI

我正在维护一个用.NET Framework构建的Windows CE应用程序，它有大约45个表单。有5个“部分”可以引导您实现所需的功能。应用程序是100%全屏的，重要的是不能最小化

由于表单太多，因此很难跟踪关闭表单后应显示的表单。为此，我将在显示窗体所有者属性之前设置它，并在关闭它时显示它的所有者

我还被告知，最好在应用程序加载时实例化所有表单，而不是为了节省处理时间而处理它们。我对此不确定

---

我的问题是，显示、隐藏表单的最佳方式是什么？您希望任何一个表单始终全屏显示在前面吗？

流程中有大量的变量，因此没有一种适合所有人的方法。当然，加载所有表单最初意味着页面间导航速度很快，但这会使加载速度变慢，并且可能会耗尽内存

我的一般方法是使用一个框架——就我个人而言，我是一个框架迷，但我可能有偏见

在任何情况下，您都需要一个通用框架来完成两件事：

将视图与模型分离（这些视图是否应为窗体、用户控件、面板或其他完全有争议的视图）

跟踪前面的视图以及“下一个”视图（无论是向前还是向后移动）

我写了一篇关于这个的简单框架文章。我对它进行了更新，使用了更纯粹的MVC和IoC框架

这并不是说我的方式是唯一的方式，甚至不是“正确”的方式。然而，我发现这种方法在桌面和设备上的多个部署中都是成功的

很难给你更多的细粒度建议，因为我们真的不知道你的需求或限制是什么。如果您运行在内存和图形负载非常有限的慢速ARM设备上，我肯定会以不同的方式攻击某些东西（缓存、延迟加载等），而不是使用内存为gig的奔腾x86嵌入式设备

编辑

你会看到，MusiGenesis和我攻击这一点的方式之间的差异突出了一个事实，即没有“正确”的方法。正如我们所说，我正在为一个有47个视图的全屏嵌入式应用程序编写代码，该项目只包含一个表单。他可能会使用47种不同的形式。两者都能完成任务。共同点是，我们都有某种形式的底层基础设施，用于处理所有需要知道顶部应该是什么的goo。他依靠ShowDialog弹出表单的本地z顺序。我依赖于一个自定义框架，它可以记住您来自哪里

---

再次强调，只要满足项目要求，就没有对错。

我不会在应用程序启动时实例化45个表单。这将严重延长启动时间，并可能（如果不是的话）耗尽内存资源，所有这些都是为了提供用户甚至不需要的功能

在我的WinMo应用程序中，每个表单都设计用于处理相对较小的数据子集，因此启动时间仅限于数据库调用和将数据加载到表单控件中。通常，实例化其中一个表单并显示它所需的时间不会超过一两秒

如果表单显示的时间超过此时间，则可能是数据检索或数据加载到表单控件的方式有问题（例如，您可能有一个自定义gridview控件，该控件可以完全呈现所有300行，即使一次只有12行可见）。如果您的数据太大，以至于检索起来需要很长时间，那么很有可能这些数据远远超出了用户实际能够与之交互的范围

我假设你提到“5个部分”以获得用户需要去的地方意味着他们可能（最多）正在“向下钻取”5个级别。如果您通过让每个表单实例化并使用

ShowDialog

显示下一个表单来实现这一点，那么您在任何时候最多会有5-6个表单，这对于.Net CF应用程序来说应该不会有任何问题（我一直都这样做）。这样，您就不必做任何特殊的事情来跟踪何时应该显示哪个表单-您只需从任何位置打开表单，当表单关闭时，您将自动返回调用表单

您必须处理一些z-order/任务管理器的奇怪之处，但并不特别复杂。在对子窗体调用

ShowDialog

之前，请将父窗体的

Text

属性设置为空字符串，然后在

ShowDialog

返回后将其设置回窗体的原始标题。这并不是绝对必要的，但在Windows Mobile（至少在版本6之前）中，所有打开的.Net表单（具有非空白文本属性）都会显示在“正在运行的程序”列表中，即使它们都来自同一个应用程序。我通常希望我的多表单应用程序看起来只是一个程序，因此我通常将每个表单的

文本设置为应用程序的名称）

我还尝试了一个表单应用程序，它将UI的每一部分实现为用户控件而不是表单，然后创建和堆叠控件，就像创建和打开表单一样。这是可行的，但它是一个黑客，我不推荐它。表单有一个加载事件，而用户控件没有，这是主要问题。
Ah，但是如果你在这些用户控件周围使用一个框架，你就可以创建自己的加载事件。呸，我甚至不再使用控件了-我只是
BitBlt
到屏幕上。：）哦，我有一个表单，有47个视图用户控件。但有趣的是，我有一个单独的自定义控件