Event声明在委托实例上添加了一层抽象和保护。此保护可防止委托的客户端重置委托及其调用列表，并且仅允许从调用列表中添加或删除目标。

An event in .net is a designated combination of an Add method and a Remove method, both of which expect some particular type of delegate. Both C# and vb.net can auto-generate code for the add and remove methods which will define a delegate to hold the event subscriptions, and add/remove the passed in delegagte to/from that subscription delegate. VB.net will also auto-generate code (with the RaiseEvent statement) to invoke the subscription list if and only if it is non-empty; for some reason, C# doesn't generate the latter.

Note that while it is common to manage event subscriptions using a multicast delegate, that is not the only means of doing so. From a public perspective, a would-be event subscriber needs to know how to let an object know it wants to receive events, but it does not need to know what mechanism the publisher will use to raise the events. Note also that while whoever defined the event data structure in .net apparently thought there should be a public means of raising them, neither C# nor vb.net makes use of that feature.

为了理解它们的区别，你可以看看这两个例子

委托的示例(在本例中是Action -这是一种不返回值的委托)

public class Animal
{
    public Action Run {get; set;}

    public void RaiseEvent()
    {
        if (Run != null)
        {
            Run();
        }
    }
}

要使用委托，你应该这样做:

Animal animal= new Animal();
animal.Run += () => Console.WriteLine("I'm running");
animal.Run += () => Console.WriteLine("I'm still running") ;
animal.RaiseEvent();

这段代码运行良好，但可能有一些弱点。

例如，如果我这样写:

animal.Run += () => Console.WriteLine("I'm running");
animal.Run += () => Console.WriteLine("I'm still running");
animal.Run = () => Console.WriteLine("I'm sleeping") ;

在最后一行代码中，我重写了前面的行为，只是缺少了一个+(我已经使用=而不是+=)

另一个弱点是每个使用Animal类的类都可以直接调用委托。例如，Animal . run()或Animal . run . invoke()在Animal类之外有效。

为了避免这些弱点，你可以在c#中使用事件。

你的动物职业会这样改变:

public class ArgsSpecial : EventArgs
{
    public ArgsSpecial (string val)
    {
        Operation=val;
    }

    public string Operation {get; set;}
} 

public class Animal
{
    // Empty delegate. In this way you are sure that value is always != null 
    // because no one outside of the class can change it.
    public event EventHandler<ArgsSpecial> Run = delegate{} 
        
    public void RaiseEvent()
    {  
         Run(this, new ArgsSpecial("Run faster"));
    }
}

调用事件

 Animal animal= new Animal();
 animal.Run += (sender, e) => Console.WriteLine("I'm running. My value is {0}", e.Operation);
 animal.RaiseEvent();

差异:

You aren't using a public property but a public field (using events, the compiler protects your fields from unwanted access) Events can't be assigned directly. In this case, it won't give rise to the previous error that I have showed with overriding the behavior. No one outside of your class can raise or invoke the event. For example, animal.Run() or animal.Run.Invoke() are invalid outside the Animal class and will produce compiler errors. Events can be included in an interface declaration, whereas a field cannot

注:

EventHandler被声明为如下委托:

public delegate void EventHandler (object sender, EventArgs e)

它接受一个发送者(Object类型)和事件参数。如果来自静态方法，则发送者为空。

这个例子使用了EventHandler<ArgsSpecial>，也可以使用EventHandler来代替。

请参阅这里有关EventHandler的文档

Delegate是一个类型安全的函数指针。事件是使用委托的发布者-订阅者设计模式的实现。

您还可以在接口声明中使用事件，但委托则不是这样。

这是另一个很好的参考链接。 http://csharpindepth.com/Articles/Chapter2/Events.aspx

简单地说，本文的要点是——事件是对委托的封装。

引用自文章:

Suppose events didn't exist as a concept in C#/.NET. How would another class subscribe to an event? Three options: A public delegate variable A delegate variable backed by a property A delegate variable with AddXXXHandler and RemoveXXXHandler methods Option 1 is clearly horrible, for all the normal reasons we abhor public variables. Option 2 is slightly better, but allows subscribers to effectively override each other - it would be all too easy to write someInstance.MyEvent = eventHandler; which would replace any existing event handlers rather than adding a new one. In addition, you still need to write the properties. Option 3 is basically what events give you, but with a guaranteed convention (generated by the compiler and backed by extra flags in the IL) and a "free" implementation if you're happy with the semantics that field-like events give you. Subscribing to and unsubscribing from events is encapsulated without allowing arbitrary access to the list of event handlers, and languages can make things simpler by providing syntax for both declaration and subscription.