代码之家  ›  专栏  ›  技术社区  ›  George Mauer

带有(object,EventArgs)参数的事件回调是否是1.1和WinForms的延迟?

  •  2
  • George Mauer  · 技术社区  · 17 年前

    因此,我最近开始玩弄FxCop,我注意到的一件事是,它坚持认为任何附加到事件的方法都应该在表单中

    void Callback(object sender, EventArgs args) { ...}
    

    并依附于

    MyObject.Event += new EventHandler(Callback);
    

    现在这一切都很好,回到过去。Net 1.1天,但从3.5开始,我发现只调用Action类型或其泛型的事件调用,并像显式调用方法一样编写方法,要简单得多,也更直观得多;对象发送器或事件处理程序都不是cruft。

    作为一个问题,我认为这是一个彻底的设计势在必行。如果你为一个事件回调设计了一个不同的方法,这意味着该方法至少隐式地包含了一些关于其调用的信息——这是一个主要的否定!

    我完全愿意接受我可能错过了什么。你们对此有什么想法,是FxCop错了还是我错了?

    2 回复  |  直到 17 年前
        1
  •  1
  •   Bill    17 年前

    你应该遵守惯例。

    1. 使用通用事件处理程序<T>,其中T是或派生自EventArgs。将活动与

      我的对象。SomeEvent+=新事件处理程序<EventArgs>(某种方法);

    2. 事件处理程序方法应该返回void(将某些内容返回给事件引发器没有意义),并且应该遵循在事件args中获取包含数据的发送方对象的约定。

    “垃圾”的原因(发送方和事件参数)

    • 可扩展性更容易实现(引发事件的类和处理事件的类)
    • 有时,你想知道是谁发送了事件。
    • 任何/所有数据都可以封装在 事件参数。
    • 你可以使用 许多事件都有相同的事件处理程序。

    这种模式还在继续。您还应该在名为OnSomeEvent()的受保护方法中引发事件“SomeEvent”,以便类的派生程序可以执行抑制事件、以线程安全的方式引发事件、在UI线程上引发事件、使用超时或异常保护引发事件、记录事件引发进程等操作。

    嘿,这不是一个完美的模式(也许发送方可以被放入事件args),但几乎所有。Net代码遵循它,框架代码始终遵循它。为什么不也跟着做呢。

        2
  •  0
  •   technophile    17 年前

    我不认为FxCop已经更新了很长一段时间;你用VS2008代码分析工具(FxCop的后继者)试过吗?

    推荐文章