c# - 事件 Action <> 与事件事件处理程序 <>

Question

声明event Action<>之间有什么不同吗？和 event EventHandler<> .

假设实际上引发事件的对象并不重要。

例如:

public event Action<bool, int, Blah> DiagnosticsEvent;

对比

public event EventHandler<DiagnosticsArgs> DiagnosticsEvent;

class DiagnosticsArgs : EventArgs
{
    public DiagnosticsArgs(bool b, int i, Blah bl)
    {...}
    ...
}

两种情况下的用法几乎相同:

obj.DiagnosticsEvent += HandleDiagnosticsEvent;

关于event EventHandler<>，有几点我不喜欢图案:

• 派生自的额外类型声明事件参数
• 强制传递对象源 –通常没人关心

更多代码意味着需要维护更多代码，但没有任何明显优势。

因此，我更喜欢event Action<>

但是，只有当 Action<> 中的类型参数过多时，才需要额外的类。

Answer 1

根据之前的一些回答，我将把我的回答分为三个方面。

首先，使用 Action<T1, T2, T2... > 的 body 限制vs 使用 EventArgs 的派生类.有三个:首先，如果您更改参数的数量或类型，则必须更改订阅的每个方法以符合新模式。如果这是第 3 方程序集将使用的面向公众的事件，并且事件参数有可能发生变化，那么为了一致性起见，这将是使用从事件参数派生的自定义类的原因(记住，您仍然可以使用 Action<MyCustomClass> ) 其次，使用 Action<T1, T2, T2... >将阻止您将反馈传递回调用方法，除非您有某种对象(例如具有 Handled 属性)与 Action 一起传递。第三，你没有得到命名参数，所以如果你传递 3 bool是一个int , 两个 string的，还有一个 DateTime ，您不知道这些值的含义是什么。 作为旁注，您仍然可以使用“在仍然使用 Action<T1, T2, T2... > 的同时安全地触发此事件的方法”。

其次，一致性影响。如果您已经在使用一个大型系统，那么遵循系统其余部分的设计方式几乎总是更好，除非您有充分的理由不这样做。如果您有需要维护的面向公众的事件，则替换派生类的能力可能很重要。请记住这一点。

第三，现实生活中的实践，我个人发现我倾向于为我需要与之交互的属性更改之类的事情创建很多一次性事件(特别是在使用相互交互的 View 模型进行 MVVM 时)或在哪里该事件只有一个参数。大多数情况下，这些事件采用 public event Action<[classtype], bool> [PropertyName]Changed; 的形式。或 public event Action SomethingHappened; .在这些情况下，有两个好处。首先，我得到一个发行类的类型。如果MyClass声明并且是唯一触发事件的类，我得到了 MyClass 的显式实例在事件处理程序中使用。其次，对于属性更改事件等简单事件，参数的含义是显而易见的，并在事件处理程序的名称中说明，我不必为此类事件创建无数类。