使用多个表单时的最佳实践-vb.net

在visual basic程序中使用许多不同的菜单/屏幕/窗体的最佳实践是什么？是否只是为我想要的每个菜单或屏幕制作一个新表单？还是有其他更好的选择

---

我不想把这件事搞得太复杂，我有一个小组项目要做，我们都有不同的技能水平。这就是说，它已经满足了我的好奇心，所以我想在开始之前问一下也无妨。

在我的情况下，当我处理多个表单时，我使用

MDI父表单来避免windows任务栏中的多个项目

另一个不寻常的解决方案是将每个表单
ShowInTaskbar
属性设置为false。
我可以看到这个问题很快就结束了，因为它太开放了，所以请允许我在这之前对此进行关键抱怨。。。否。TabControl页的可见属性？说真的，微软

这就引出了关键点。如果表单在某种程度上是相关的，但不一定完全相同，那么我更喜欢使用具有不同选项卡的单个表单，尽管控件中存在明显的缺陷。（你不必花太多的时间来寻找解决方法，但解决方法仍然是一种解决方法。）在运行时动态操纵控件是这件事的另一面，尽管我倾向于很少使用它。。。但那只是个人的事情

例如，在最近的一个应用程序中，我有几种类型对象的列表。它们是相关的，但执行了完全不同的功能，用户实际上不需要一次查看多个列表。因此，我使用了一个表单，每个对象列表都有一个选项卡，以减少用户显示的混乱

类似地，最近在做GL应用程序时，我将日记账标题和日记账行条目（它们进入后端数据库中的不同表）放在一个表单的不同部分。另一方面，尽管创建过程共享一些底层数据，但资产创建的差异很大，因此我创建了一个不同的表单。（即日记帐行数据。）

我不相信“最佳实践”的概念，因为在一种情况下好的实践在另一种情况下可能是非常糟糕的。然而，我使用的“经验法则”是：
-将表单数量保持在最低限度，以降低开销并减少维护，但
-如果两个函数之间没有逻辑上的“联系”，那么不要害怕创建一个新的表单，因为试图维护一个执行7个不同角色的表单肯定会导致疯狂和沮丧，特别是当您无意中破坏了某个表单时

是的，这两条规则是冲突的，但在某种程度上，我认为设计的这一方面类似于数据库规范化；过度规范化（每个显示都有一个单独的表单）和欠规范化（试图将太多不相关的函数合并到一个表单中）之间有一个最佳点。至少规则总是让我停下来思考“我需要这个表格，还是它与我已经做过的事情有关？”

第三条经验法则显然是。。。始终从用户的角度来看待它。他们会觉得你把他们弹得太多了吗？所有表单是否都有相同的外观和感觉，更重要的是，控制布局，使它们始终知道在哪里可以找到东西

所有这些都会因应用程序的不同而有所不同，并且没有一种尺寸适合所有IMHO。
基于浏览器或Windows的表单？请澄清您的要求。您将拥有多少不同的功能区域？解决方案取决于您的需要。除非它是一个小项目（就像OP的问题中可能存在的那样），否则我会避免使用MDI概念-如果使用Microsoft的方式，它的生产效率可能会降低。