'UserControl'构造函数中的参数在C＃ [英] 'UserControl' constructor with parameters in C#

问题描述

叫我疯狂，但我是一个喜欢带参数的构造函数（如果需要），而不是一个没有参数的构造函数，然后设置属性的类型。我的思想过程：如果属性需要实际构造对象，他们应该在构造函数中。我有两个优点：

Call me crazy, but I'm the type of guy that likes constructors with parameters (if needed), as opposed to a constructor with no parameters followed by setting properties. My thought process: if the properties are required to actually construct the object, they should go in the constructor. I get two advantages:

1. 我知道当一个对象被构造（没有错误/异常），我的对象是好的。 >
   
2. 它有助于避免忘记设置某个属性。

这种心态开始伤害我形成/用户控制开发。想象这个UserControl：

This mindset is starting to hurt me in regards to form/usercontrol development. Imagine this UserControl:

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

在设计时，如果我将此UserControl ，我得到一个例外：

At designtime, if I drop this UserControl on a form, I get an exception:

无法创建组件MyUserControl...

System.MissingMethodException - No无参数的构造函数。

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

对我来说，唯一的办法是添加默认构造函数其他人知道一种方式）。

It seems like, to me, the only way around that was to add the default constructor (unless someone else knows a way).

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属性来做类似的事情：

The whole point of not including the parameterless constructor was to avoid using it. And I can't even use the DesignMode property to do something like:

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将如下所示：

I have my parameterless constructor, I can drop it on the form, and the form's InitializeComponent will look like this:

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

  // blah, blah
}

，因为我做了（是的，忽略Visual Studio生成的评论），我试图搞砸，我传递参数到InitializeComponent，以便我可以将它们传递给MyControl的构造函数。

And trust me, because I did it (yes, ignoring the comments Visual Studio generated), I tried messing around and I passed parameters to InitializeComponent so that I could pass them to the constructor of MyControl.

这导致我这样：

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

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

对于我使用UserControl参数的构造函数，第二个构造函数，我不需要？并实例化控件两次？

For me to use a UserControl with parameters to the constructor, I have to add a second constructor that I don't need? And instantiate the control twice?

我觉得我一定做错了。想法？意见？保证（希望）？

I feel like I must be doing something wrong. Thoughts? Opinions? Assurance (hopefully)?

推荐答案

关于Windows窗体工作方式的设计决策或多或少排除Windows窗体组件的参数化。你可以使用它们，但是当你做的时候，你会走出通常认可的机制。相反，Windows窗体更喜欢通过属性初始化值。这是一个有效的设计技术，如果没有广泛使用。

Design decisions made regarding the way Windows Forms works more or less preclude parameterized .ctors for windows forms components. You can use them, but when you do you're stepping outside the generally approved mechanisms. Rather, Windows Forms prefers initialization of values via properties. This is a valid design technique, if not widely used.

这有一些好处。

1. 客户易于使用。客户端代码不需要跟踪一堆数据，它可以立即创建一些东西，只是看到它与明智的（如果不感兴趣的）结果。


2. 设计器的易用性。设计师代码更清晰，更易于解析。


3. 避免单个组件中异常的数据依赖。 （虽然即使微软也会使用 SplitContainer ）

1. Ease of use for clients. Client code doesn't need to track down a bunch of data, it can immediately create something and just see it with sensible (if uninteresting) results.
2. Ease of use for the designer. Designer code is clearer and easier to parse in general.
3. Discourages unusual data dependencies within a single component. (Though even microsoft blew this one with the SplitContainer)

表单中有很多支持，技术也。像 DefaultValueAttribute ， DesignerSerializationVisibilityAttribute 和 BrowsableAttribute 让您有机会以最小的努力提供丰富的客户体验。

There's a lot of support in forms for working properly with the designer in this technique also. Things like DefaultValueAttribute, DesignerSerializationVisibilityAttribute, and BrowsableAttribute give you the opportunity to provide a rich client experience with minimal effort.

（This isn'抽象基类组件也可以变得毛茸茸。）

(This isn't the only compromise that was made for client experience in windows forms. Abstract base class components can get hairy too.)

我建议坚持一个无参数的构造函数和工作在窗体内设计原则。如果您的 UserControl 必须强制执行，那么将它们封装在另一个类中，然后通过属性将该类的实例分配给您的控件。这将更好地分离关注。

I'd suggest sticking with a parameterless constructor and working within the windows forms design principles. If there are real preconditions that your UserControl must enforce, encapsulate them in another class and then assign an instance of that class to your control via a property. This will give a bit better separation of concern as well.

这篇关于'UserControl'构造函数中的参数在C＃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！