事件的好处~实现对修改的封闭，对扩展的开放

事件是这样的，我觉得用事件来做这事比较好，它很好的遵循了“开闭原则”，当然这并不是最重要的，最重要的应该是它更符合程序开发的原则。

场合：一个订单处理问题，一个订单的产生可能由多种途径生成，Ａ产品走Ａ产品的订单处理过程，完成后显示Ａ产品的订单成功页，Ｂ产品走Ｂ产品的购买流程，完成后，显示Ｂ产品听订单成功页，当然陆续可能会有Ｃ产品，Ｄ产品等等

实现：不考虑订单处理业务，只考虑订单成功页的显示

解决１：由Ａ产品页向订单统一处理程序传递参数，在订单统一处理程序里去判断参数，然后显示信息

解决２：Ａ产品订阅一个事件，去返回订单成功后显示的页面，在订单统一处理程序里触发这个事件，然后自己显示指定信息

从上面两解决解决方法中，可以看到“方法２”更加灵活，更符合面向对象的原则，“原则”不是说说而以的，它确实有它的意思，有它的好处，当有Ｃ产品，Ｄ产品出现时，只需要修改Ｃ和Ｄ对应的部门就可以了，而“单统一处理程序”不需要做修改，而“方法１”则需要修改“单统一处理程序”，这样做下去会使你的程序的维护性和扩展性大打折扣。

代码如下：

/// <summary>
    /// 返回一条特定的消息
    /// </summary>
    public class ReturnMessage
    {
        #region Events
        /// <summary>
        /// 重定向事件
        /// </summary>
        public static event ReturnMsgEventHandler ReturnMsg;
        #endregion

        #region OnEvents Methods
        /// <summary>
        /// 触发重定向事件
        /// </summary>
        public static string OnReturnMsg()
        {
            if ((ReturnMsg != null))
            {
                return ReturnMsg();
            }
            else
                return "查看已买到的课程";
        }
        #endregion

    }
    #region Delegates
    /// <summary>
    /// 返回一个字符串消息的委托
    /// </summary>
    public delegate string ReturnMsgEventHandler();
    #endregion

在主程序中触发时可以这样：

ViewData["Msg"] = ReturnMessage.OnReturnMsg();

在订阅时可以这样：

ReturnMessage.ReturnMsg += new ReturnMsgEventHandler(ReturnMsg_ReturnMsg);

string ReturnMsg_ReturnMsg()
     {
         return "产品Ｃ成功";
     }

也可以使用匿名方法，写在一行：

ReturnMessage.ReturnMsg +=  delegate(){return "产品Ｃ成功";};