目前我的Form1代码非常繁重,主要是菜单和控件事件。我想做的一件事是以某种方式组织它,所以我可以扩展或折叠“相关代码”(在Visual Studio中)。
我的第一次尝试是将与主菜单相关的代码放在一个名为“MainMenu”的嵌套类中,该类位于Form1类中,这样我就可以简单地折叠嵌套类。需要它。这导致了各种各样的问题(即我找不到在这个嵌套类中设置主菜单的方法)。
我缺少一个更简单的解决方案吗?或者有人可以解释为什么我的嵌套类想法有问题?
答案 0 :(得分:15)
虽然@testalino's answer确实符合您的要求,但我会说您的真正的问题可能与代码设计有关。有可能表单类只包含了比应该更多的代码,并且其中一些代码应该转移到其他类中。
如果做得好,这可能会带来一些好处:
答案 1 :(得分:12)
您可以使用#region和#endregion来组织类中的代码。然后这些地区就会崩溃。
答案 2 :(得分:6)
我建议你使用用户控件来封装Form的一些行为。我想这是目前最简单的解决方案。您只需选择一些用户界面并将其提取到用户控件并定义一些可从表单访问的公共属性。
在Form.cs中保留所有处理程序是一个糟糕的坏习惯。你必须避免使用它,因为它是不可能的(我已经看到了很多类似的代码,并且在后期阶段添加或更改功能被证明是不可能的,不会破坏任何东西,更不用说更改UI而不影响应用程序的工作方式)。
将来,您可能希望尝试从应用程序逻辑中分离UI的不同方法,例如:探索MVP / MVC模式。
答案 3 :(得分:2)
如果您的表单变得如此庞大和复杂,以至于您突然希望以某种方式组织它,则强烈暗示需要重构,这将提高代码的可读性,可测试性和可维护性。您实际重构的 取决于您的实际代码。
这是一个有很多控件的表单吗?考虑在单独的UserControl中将其拆分,其中每个UserControl都显示域数据的某个方面。你有很多交互逻辑,对很多事件做出反应吗?也许会引入某种Controller或EventAggregator。
有许多众所周知的模式可以帮助您组织UI和域代码。 This series正在讨论这个问题,并向您介绍模式MVC,MVP,EventAggregator等等。它会根据您的需要在Windows窗体的上下文中讨论模式。
答案 4 :(得分:2)
使用partial class关键字将您的班级拆分为多个文件。
答案 5 :(得分:1)
我同意其他答案所说的关于在#regions中将相似的事件处理程序分组在一起的内容是非常可靠的。此外,如果处理程序中的代码本身也很庞大,您可能想要将这些代码重构为逻辑业务逻辑类。例如:
之前的伪代码:
private void SomeButton_Click(...)
{
using (FileStream fs = ...)
{
fs.Write(some form data);
fs.Write(some more form data);
}
DoMoreBusinessLogicStuff();
...
// lots more stuff
...
}
之后的伪代码:
private void SomeButton_Click(...)
{
IBusinessObject obj = new BusinessObject(injectable form data);
using (IPersistence store = new FilePersistence(...))
{
obj.Persist(store);
}
obj.DoBusinessRules();
}
这应该将业务,持久性和支持逻辑移动到他们自己的类中,并将事件处理程序保留为轻量级shell,仅用于收集UI输入并将其传递。
答案 6 :(得分:0)
嵌套类通常不赞成只是从上帝类中略微升级一件事,封装和代码重用非常模糊。
你应该的目标是在你的代码中表达你实际拥有的对象作为单独的业务类:一个类,一个文件。你有没有特别的理由这样做?
答案 7 :(得分:0)
取决于它所执行的代码类型将取决于您可以移动它的位置。
如果它处理数据代码,那么您可以将其移出到不同命名空间中的不同类中,将处理后的数据返回到控件以允许数据绑定等。
如果Form1的代码变得非常繁重,那么这是因为你在Form1中进行了太多的事情吗?你能把它分解成一个不同的/新的形式吗?
答案 8 :(得分:0)
你可以使用可折叠的摘要,但我认为这更倾向于为其他开发者提供信息,但总是很好的做法!
在VB中:
''' <summary>
'''
''' </summary>
''' <remarks></remarks>
在C#中
/// <summary>
///
/// </summary>
/// <remarks></remarks>