Winforms 和 ASP.NET 中的重构

发布于 2024-12-15 17:51:40 字数 604 浏览 0 评论 0原文

当我为 Winforms 和 ASP.NET 制作用户控件时，我发现自己为表单上的每个属性一遍又一遍地编写相同的代码部分，这就是：

private string _url;

public string Url
{
  get { return _url; }
  set
  {
    if (_url == value)
      return;

    _url = value;
    OnUrlChange(EventArgs.Empty);
  }
}

public event EventHandler UrlChanged;

protected virtual void OnUrlChange(EventArgs e)
{
  //Maybe add some extra logic here

  if(UrlChanged != null)
    UrlChanged(this, e);
}

有时会有奇怪的变化。也许我会编写自己的从 EventArgs 派生的类并使用它。

这似乎是一项常见任务。也许我做错了，有更简单的方法来写很多东西吗？但如果没有，是否可以设置任何自定义重构工具来填充给定属性名称 Url 的代码？

原文

When I'm making user controls for both Winforms and ASP.NET, I find myself writing the same section of code over and over again for each property on the form, which is this:

private string _url;

public string Url
{
  get { return _url; }
  set
  {
    if (_url == value)
      return;

    _url = value;
    OnUrlChange(EventArgs.Empty);
  }
}

public event EventHandler UrlChanged;

protected virtual void OnUrlChange(EventArgs e)
{
  //Maybe add some extra logic here

  if(UrlChanged != null)
    UrlChanged(this, e);
}

Sometimes there's the odd change. Maybe I'll writing my own class that derives from EventArgs and use that.

This seems like it must be a common task. Maybe I'm doing it wrong and there's a much easier way to write the lot? But if not, are there any custom refactoring tools that I can set up to fill in this code given the Property name Url?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

最笨的告白 2024-12-22 17:51:40

您的模式非常常见，并且几乎是实现此目的的最佳方法。

话虽如此，您绝对应该使用 Visual Studio Snippets 。它们允许轻松地为这样的代码创建模板。您可以定义自己的占位符，当您插入代码片段时，Visual Studio 会突出显示占位符并允许您通过 Tab 键浏览它们。

我还推荐 Snippet Designer 插件，它将使代码片段创建变得更容易、更有趣。它还有助于找出您不知道存在的片段功能。

回复收藏 0 原文

月牙弯弯 2024-12-22 17:51:40

几个月前我就考虑过这个问题，并尝试过使用它：

    public event PropertyChangedEventHandler PropertyChanged;

    int _MyProperty;
    public int MyProperty
    {
        get { return _MyProperty; }
        set { ChangeIfUnequal(ref _MyProperty, value, "MyProperty"); }
    }

    int _AnotherProperty;
    public int AnotherProperty
    {
        get { return _AnotherProperty; }
        set { ChangeIfUnequal(ref _AnotherProperty, value); }
    }


    void ChangeIfUnequal<T>(ref T Val, T NewValue, string Identifier="")
    {
        if (!Val.Equals(NewValue))
        {
            Val = NewValue;
            var temp = PropertyChanged;
            if(temp != null)
                temp(this, new PropertyChangedEventArgs(Identifier));
        }
    }

但我从未在生产中运行过它，也没有花足够的时间来思考这是否是一个边际改进或不必要的复杂化。毫无疑问，它不如在每个属性中显式设置它那么灵活，因为这只会在 !equals 上引发。我想要么接受要么离开。

I had thought about this some couple of months ago and toyed with using this:

    public event PropertyChangedEventHandler PropertyChanged;

    int _MyProperty;
    public int MyProperty
    {
        get { return _MyProperty; }
        set { ChangeIfUnequal(ref _MyProperty, value, "MyProperty"); }
    }

    int _AnotherProperty;
    public int AnotherProperty
    {
        get { return _AnotherProperty; }
        set { ChangeIfUnequal(ref _AnotherProperty, value); }
    }


    void ChangeIfUnequal<T>(ref T Val, T NewValue, string Identifier="")
    {
        if (!Val.Equals(NewValue))
        {
            Val = NewValue;
            var temp = PropertyChanged;
            if(temp != null)
                temp(this, new PropertyChangedEventArgs(Identifier));
        }
    }

But I never ran it in production and haven't spent enough time to think if this is a marginal improvement or unnecessary complication. Undoubtedly it's not as flexible as explicitly setting it in each property as this would only raise on !equals. Take it or leave it I guess.

回复收藏 0 原文