c# - C# 中带参数的 'UserControl' 构造函数

标签 c# winforms parameters constructor user-controls

说我疯了,但我是那种喜欢带参数的构造函数(如果需要的话)的人,而不是不带参数的构造函数,然后设置属性。我的思考过程:如果实际构造对象需要属性,则它们应该放在构造函数中。我有两个优势:

  1. 我知道当一个对象被构建时(没有错误/异常),我的对象是好的。
  2. 这有助于避免忘记设置某个属性。

在表单/用户控件开发方面,这种心态开始伤害我。想象一下 UserControl :

public partial class MyUserControl : UserControl
{
  public MyUserControl(int parm1, string parm2)
  {
    // We'll do something with the parms, I promise
    InitializeComponent();
  }
}

在设计时,如果我删除这个 UserControl在表格上,我得到一个 Exception :

Failed to create component 'MyUserControl' ...
System.MissingMethodException - No parameterless constructor defined for this object.

在我看来,唯一的解决办法就是添加默认构造函数(除非其他人知道办法)。

public partial class MyUserControl : UserControl
{
  public MyUserControl()
  {
    InitializeComponent();
  }

  public MyUserControl(int parm1, string parm2)
  {
    // We'll do something with the parms, I promise
    InitializeComponent();
  }
}

不包括无参数构造函数的全部意义在于避免使用它。我什至不能使用 DesignMode属性做类似的事情:

public partial class MyUserControl : UserControl
{
  public MyUserControl()
  {
    if (this.DesignMode)
    {
      InitializeComponent();
      return;
    }

    throw new Exception("Use constructor with parameters");
  }
}

这也行不通:

if (LicenseManager.UsageMode == LicenseUsageMode.Designtime)

好吧,继续……

我有我的无参数构造函数,我可以将它放在表单上,​​表单的 InitializeComponent看起来像这样:

private void InitializeComponent()
{
  this.myControl1 = new MyControl();

  // blah, blah
}

相信我,因为我做到了(是的,忽略了 Visual Studio 生成的注释),我试着乱搞并将参数传递给 InitializeComponent这样我就可以将它们传递给 MyControl 的构造函数.

这让我想到了这个:

public MyForm()
{
  InitializeComponent(); // Constructed once with no parameters

  // Constructed a second time, what I really want
  this.myControl1 = new MyControl(anInt, aString);  
}

我要用 UserControl带有构造函数的参数,我必须添加我不需要的第二个构造函数?并将控件实例化两次?

我觉得我一定做错了什么。想法?意见?保证(希望如此)?

最佳答案

关于 Windows 窗体工作方式的设计决策或多或少排除了 Windows 窗体组件的参数化 .ctors。您可以使用它们,但是当您这样做时,您就超出了普遍认可的机制。相反,Windows 窗体更喜欢通过属性初始化值。如果没有广泛使用,这是一种有效的设计技术。

不过,这有一些好处。

  1. 易于客户使用。客户端代码不需要追踪一堆数据,它可以立即创建一些东西,然后只看到它的合理(如果无趣)结果。
  2. 易于设计人员使用。一般来说,设计器代码更清晰、更易于解析。
  3. 不鼓励在单个组件中存在异常的数据依赖性。 (尽管微软甚至用 SplitContainer 搞砸了这个)

在表单中也有很多支持,可以在这种技术中与设计人员一起正常工作。像 DefaultValueAttribute 这样的东西, DesignerSerializationVisibilityAttribute , 和 BrowsableAttribute让您有机会以最少的努力提供丰富的客户体验。

(这不是为 Windows 窗体中的客户端体验做出的唯一妥协。抽象基类组件也可能变得毛茸茸。)

我建议坚持使用无参数构造函数并遵循 Windows 窗体设计原则。如果确实存在您的 UserControl 必须强制执行的先决条件,请将它们封装在另一个类中,然后通过属性将该类的一个实例分配给您的控件。这也会提供更好的关注点分离。

关于c# - C# 中带参数的 'UserControl' 构造函数,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1784303/

相关文章:

ant - 如何将参数值传递给maven gzip ant任务?

c# - 如何在连接前获取MAC地址?

c# - 可以通过 Internet 使用 AD 来验证用户身份吗?

c# - IDbAsyncEnumerable 未实现

winforms - WinForms 上的多项选择

c# - 解释用户控件中自定义事件的代码

c# - 在 Controller 和 View 之间传递数据 - ASP.NET MVC 4

c# 表单最小化/最大化按钮不见了?

parameters - 在开放的 CL 中将结构数组传递给内核

java - 如何从java类中获取方法参数名称?