在做系统开发时，经常会遇到一个关键操作的过程中，需要处理很多关联操作，最要命的是，有些关联操作都不是可以预见的。例如：我们在做一个零售系统的过程中，销售主流程的操作无非就是：下单（创建订单）、结算（支付成功）简单来看，最主要的动作就是这两个（当然根据你的业务需要，可以再细化。这里不要做主要分析）。
那么问题来了，随着时间的推移、业务发展，下单时可能需要：
1、给运营人员一个通知;
2、关联锁定库存;
...
同样，结算的时候，可能需要：
1、给用户发一个支付通知;
2、给老板发一个收款通知;
3、给仓库发一个发货通知;
...
那么问题来了，在一个动作上，可能绑定的操作这么多，而且还不确定？什么办？如果在主流程的操作方法里面做更改，那将是开发的噩梦！随着需求变更，或者随着关联任务的增加，那么这个主流程的方法会越来越长，流程逻辑会越来越复杂。那么面对这种情况，最佳的程序设计应该是引入事件的概念（传统的Windows的开发基本都是基于事件的）。C#的开发也是支持事件的。那么在基于事件的开发前，先要搞懂委托，在C#里委托很重要，异步开发做回调要用到委托，事件这里也要用到委托，其实我的理解是事件跟回调的开发思路类似，都是在XXX操作完成/开始/执行时，调用一个外部的方法。回调一般是调用一个固定方法，事件是可以在监听器上附加多个监听方法，当监听到事件触发，每个监听的方法只需要执行自己的逻辑，基本上都可以互不干扰。
对的，事件的开发有几个关键东东：监听器，触发器。
假设我们定义一个委托：
public delegate void OrderEventHander(UserOrder sender,EventArgs e);
这里我们定义一个订单委托，这个委托的意思就是，但凡遇到类型为OrderEventHander的事件，处理的监听方法按照该委托定义的参数传值。
接下来看如何用这个委托：
public class UserOrder
{
/// <summary>
/// 当支付成功，已经完成订单支付成功状态更改时触发
/// 这里只是在收到订单成功支付的微信通知，并修改订单支付状态后触发
/// </summary>
public static event OrderEventHander OnPaySuccess;
public static UserOrder SetUserOrderPaySuccess(Guid orderunid)
{
UserOrder result;
result=;//这里是订单支付成功并修改相关相关数据状态的过程
//订单状态修改，在系统内就是成功支付状态，促发支付成功事件
//这里是调用触发器，并按照委托的方法格式传值
OnPaySuccess?.Invoke(result, new EventArgs());
return result;
}
｝
在对象内，用event关键字声明一个事件(触发器)，这个事件的类型为上面定义的委托类型，表示这个事件的监听处理方法按照上面定义的委托的参数格式来接收参数。在执行订单状态更改的主方法内，通过
OnPaySuccess?.Invoke(result, new EventArgs());
来调用触发器，这句的意思是当事件OnPaySuccess有附加监听方法，则执行该触发器。这里我们的event是以static方式声明，是可以全局附加监听器，每一个触发器都可以附加多个监听器(监听方法)。
通常使用事件，就是给事件触发器附加上监听方法：
UserOrder.OnPaySuccess += UserOrder_OnPaySuccess;
一般用+=来给触发器附加监听方法，
+=的左边是事件触发器，
+=右边是事件监听器(监听方法)
没一个触发器是主方法内通过类似
OnPaySuccess?.Invoke(result, new EventArgs());
的语句来调用触发。主程序执行到该语句时，才会根据事件触发器+=的顺序来执行右边的监听方法。