哪个具有更好的性能，Action 或 Wiring to Event

Question

背景故事：

所以我正在尝试回答这个问题，但我不确定如何去做。我想也许这里有人有很好的学习资源或者可以给出明确的答案。

简而言之，我想知道什么在性能上更好以及在标准 C# OOP 编程中什么是更好的实践。

问题：

是连接到一个事件更好，还是让消费者注入一个可以调用结果的动作更好？

示例：

例如，我正在构建一个搜索面板。我的面板应该非常擅长搜索，但并不真正关心其结果的使用方式。

所以我的两个选择是，在我的视图模型中创建一个完成的事件并从任何关心结果的地方连接到它，或者选项二，允许调用者注入一个回调操作，当搜索完成。

我最初的想法是至少它们是相等的，因为事件和动作都应该只是一个被调用的函数引用指针。但是，我可以看到气泡事件的性能较低。

示例代码：

public class Consumer{

    public Consumer(){
          StandardViewModel viewModel = new StandardViewModel(CompletedCallback);
          viewModel.customEvent += someEventHandler;
    }

    public void someEventHandler(Object sender, EventArgs args){
       // do something with results
    }
    public void CompletedCallback(List<string> results){
       // do something with results
    }

}


public class StandardViewModel{
    public event EventHandler customEvent;
    private Action<IEnumerable<string> _callback;
    public StandardViewModel(Action<IEnumerable<string>> callback){
           _callback = callback;
    }
}

Answer 1

性能差异很小。

事件由编译器生成的委托字段实现。当只有一个订阅者附加到事件（通常情况）时，委托就像手动委托一样。
事件通常有 object sender, EventArgs args 个参数（尽管这是可选的）。这可能会导致微小的性能差异。与仅将委托传递给构造函数相比，附加到事件的性能成本也很小。
.NET 中没有事件 "bubble"。

这些都是非常次要的点。

基于代码质量问题应该使用哪种回调样式？

当您进行回叫时，以后无法更改回叫。活动始终会有一位订阅者。
您还可以验证此委托是否为空。
您也可以将此委托传递给其他代码。这对于事件来说是不可能的。
在活动版本中，您真的被迫不在乎有多少订阅者。可能有零个或多个。订户列表可以随时更改。从这个角度来看，这更灵活。

使用哪种样式取决于 class 应该如何使用。在这里，我更喜欢位的事件样式，因为您真的不会以任何方式关注订阅者列表。

哪个具有更好的性能，Action 或 Wiring to Event

Which has better performance, Action or Wiring to Event

c#

performance

standards