在此记录下Eventhandler开发中曾经走过的弯路和一点心得......
曾经的项目中有个小需求,在一个list中创建一个Choice类型的字段,名为Status,分别有"Not Started","In Progress","On Schedule","ahead of Schedule","Delayed","Done"等等用来表示进度的字段,要求当这个item的Status值从"Not Started"变为"In Progress"时,给项目经理发邮件,当从"In Progress"变为"ahead of Schedule"时给整个项目组加上部门经理发邮件。
需求就这么简单,当时也没多想,就用Eventhandler实现了,大致代码如下:
string currentStatus = properties.AfterProperties["Status"] as String;
if(previousStatus == "Not Started"&¤tStatus == "In Progress")
{
SendEmail(mgr);
}
if(previousStatus == "In Progress"&¤tStatus == "ahead of Schedule")
{
SendEmail(director);
}
很好,这样的Eventhandler完成了需求,简单明了。跑了一段时间,业务需求发生变化了,当从"In Progress"变成"Done"时也要发邮件给Mgr,于是又修改了代码中的if condition,但是需求总是在变化,有时候在Eventhandler中不仅涉及到了Stauts字段变化的处理还有别的字段变化处理,总之 if condition到后来变的象面条一样冗长,让人看了很不舒服,维护起来也很麻烦了。
在代码review中,我们认识到了这样的需求变化在Eventhandler开发中太常见了,于是打算用State模式来改写以前的代码,使得我们的扩展更加方便:
State模式的应用场景:在你的类里面有个型别码来表示对象的当前状态,这个对象的行为通常依赖这个状态,而且在运行的时候这个状态会改变,那么对象的行为在运行的时候也要跟着改变。一般我们会使用if/else或者switch来根据这个型别码来执行相关操作,现在我们有更好的方式来处理--State模式。
好像这个场景很符合我们当前的情况,于是我们就开始改写代码了。根据State模式类图,首先创建State的抽象类
{
public abstract void Select();
}
其次为每个可能的状态编写状态类,继承自State类
{
public override void Select()
{
SendEmail(mgr);
}
class AheadOfSchedule:State
{
public override void Select()
{
SendEmail(director);
}
还有Context类:
{
State _currentState;
string _currentValue;
public State CurrentState { get; set; }
public string CurrentValue{ get; set; }
public void Process()
{
switch (CurrentValue)
{
case "In Progress":
{
CurrentState = new InProgressState();
CurrentState.Select();
return;
}
case "Ahead of Schedule":
{
CurrentState = new AheadOfSchedule();
CurrentState.Select();
return;
}
default:
{
return;
}
}
}
}
Eventhandler调用代码:
{
string currentStatus = properties.AfterProperties["Status"] as String;
}
当然这里还没有做到完全抽象,但较之前的情况已经好了很多。
当以后还遇到在Eventhandler中涉及到状态改变的复杂逻辑时,先考虑State模式会很有好处。