职责链模式在开发中的应用

我在《软件设计精要与模式》第19章中介绍了职责链模式在实际项目中的应用,由于引入了该模式,使得对象在职责划分上有了更清晰的结构,然而由于项目场景的诸多限制,总有几分“为模式而模式”的生涩感觉。最近在开发WCF的相关项目时,又一次应用了职责链模式,一方面加深了自己对设计模式的进一步理解,也积累了一些心得,可以与各位分享。
 
在该项目中,我希望实现对Endpoint的合法性检验,其中对于绑定而言,则包含了许多约束,例如绑定与URI样式的约束,例如绑定与服务契约设计的约束。绑定不同,则向对应的约束也不相同。为了更好地体现Endpoint,我在项目中定义了属于自己的Endpoint类:
    public class ServiceEndpoint
    
{
        
public Uri Address
        
{
            
get;
            
set;
        }


        
public Binding Binding
        
{
            
get;
            
set;
        }


        
public Type ContractType
        
{
            
get;
            
set;
        }

    }

如果考虑最简单的实现方式,我们完全可以通过分支语句,判断不同的绑定类型,然后执行对绑定约束的检查,例如:

public class BindingConstraint

{

public bool Constraint(ServiceEndpoint endpoint)

{

bool flag = false;

switch (endpoint.Binding.Name)

{

case "BasicHttpBinding":

//check the BasicHttpBinding;

 

flag = true;

break;

case "NetTcpBinding":

//check the NetTcpBinding;

break;

case "NetPeerTcpBinding":

//check the NetPeerTcpBinding;

break;

//...Other bindings' constraint;

}

 

return flag;

}

}

这是一个合适的设计,无可厚非。然而,我们所面临的关于绑定的约束性检查,远非几行代码就可以实现。例如,对于WSDualHttpBinding绑定而言,我们就需要判断传递进来的契约类型是否具有回调契约。当然,我们可以分别将这些约束性检查放入到专门的方法,甚至是专门的类中,但不可避免的是,我们会让Constraint方法的switch语句变得越来越长。
 
这还不是关键的,最主要的是我们需要检查的绑定存在扩展的可能,因为除了WCF自身提供的绑定类型之外,我们还可以提供CustomBinding或其它自定义绑定,一旦可能增加绑定,就需要修改这里的Constraint()方法。这样的设计就难免捉襟见肘了。事实上,在.NET Framework 3.5中,微软就为WCF新增加了几个绑定,例如WebHttpBinding。
 
此时,我们就可以考虑采用职责链模式,由于我们是针对绑定类型进行约束性检查,我们可以为每个绑定类型定义一个约束对象,然后对其进行抽象,设计类图如下所示:
chainofresponsibility.gif

首先,我们需要定义一个基类BindingConstraint,如下所示:
    public abstract class BindingConstraint//:IEndpointConstraint
    {
        
protected fields

        
public methods        

        
public abstract methods

    }

这是一个抽象类,包含了两个protected字段,其中m_bindingConstraint即形成职责链的关键,通过AddConstraint()方法可以将BindingConstraint对象加入到职责链中,而字段m_hasNextConstraint则用来标识当前对象之下是否还存在BindingConstraint对象。抽象方法Constraint()则实现约束性检查的业务逻辑,同时还包括对职责链是否存在下一个职责对象的判断。例如BasicHttpBindingConstraint的定义如下:
    public class BasicHttpBindingConstraint:BindingConstraint
    
{
        
public override bool Constraint(ServiceEndpoint endpoint)
        
{
            
if (endpoint.Binding.Name == "BasicHttpBinding")
            
{
                
//check BasicHttpBinding Constraint;
                BasicHttpBinding binding = endpoint.Binding as BasicHttpBinding;
                //...

                
//check binding and address's scheme                if (endpoint.Address.Scheme.ToLower() != "http" && endpoint.Address.Scheme.ToLower() != "https")
                
{
                    
throw new BindingConstraintException("the binding is mismatch with address schema.");
                }
                

                
return true;
            }

            
else
            
{
                
if (m_hasNextConstraint)
                
{
                    
return m_bindingConstraint.Constraint(endpoint);
                }

                
else
                
{
                    
return false;
                }

            }

        }

    }

根据传入的endpoint对象,判断绑定的名称是否为"BasicHttpBinding",如果是,则执行该约束对象的约束性检查,如果不是,则去寻找职责链中的其它对象(根据m_hasNextConstraint判断)。正是通过这样的实现方式,当客户端调用BindingConstraint的Constraint()方法时,就可以根据传入的ServiceEndpoint对象,智能地找到符合自己条件的BindingConstraint对象,并执行Constraint()方法进行约束性检查。
 
在我的《软件设计精要与模式》一书中,在应用职责链模式时,我的建议是最好提供专门创建职责链的工厂类,在本例中自然也不例外:
    public class BindingConstraintFactory
    
{
        
public static BindingConstraint CreateConstraint()
        
{
            BindingConstraint basicHttp 
= new BasicHttpBindingConstraint();
            BindingConstraint netTcp 
= new NetTcpBindingConstraint();
            BindingConstraint netPeerTcp 
= new NetPeerTcpBindingConstraint();
            BindingConstraint netNamedPipe 
= new NetNamedPipeBindingConstraint();
            BindingConstraint wsHttp 
= new WSHttpBindingConstraint();
            BindingConstraint wsFederationHttp 
= new WSFederationHttpBindingConstraint();
            BindingConstraint wsDualHttp 
= new WSDualHttpBindingConstraint();
            BindingConstraint netMsmq 
= new NetMsmqBindingConstraint();
            BindingConstraint msmqIntegration 
= new MsmqIntegrationBindingConstraint();

            netMsmq.AddConstraint(msmqIntegration);
            wsDualHttp.AddConstraint(netMsmq);
            wsFederationHttp.AddConstraint(wsDualHttp);
            wsHttp.AddConstraint(wsFederationHttp);
            netNamedPipe.AddConstraint(wsHttp);
            netPeerTcp.AddConstraint(netNamedPipe);
            netTcp.AddConstraint(netPeerTcp);
            basicHttp.AddConstraint(netTcp);

            
return basicHttp;
        }

    }

通过CreateConstraint()方法,就可以像穿珠子一般,形成一条隐藏的职责链(在创建这样的职责链时,需要注意职责对象的先后次序),然后在客户端代码中,可以非常优雅的实现对绑定的约束性检查:

private static BindingConstraint m_bindingConstraint = BindingConstraintFactory.CreateConstraint();

 

public void AddServiceEndpoint(ServiceEndpoint endpoint)

{

if (m_bindingConstraint.Constraint(endpoint))

{

m_endpointsList.Add(endpoint);

}

}


不管传入的endpoint是何种类型的绑定,只要在职责链中创建了相对应的绑定约束对象,都可以进行约束性检查,且逻辑清楚,职责明确。如果对绑定进行了扩展,我们只需要新增对应的绑定约束对象,然后修改BindingConstraintFactory工厂类的工厂方法即可。
 
使用职责链模式必须恰到好处,否则会成为模式滥用的反面教材。根据我对职责链模式的理解,可以认定只要同时符合下列三个条件,就可以引入职责链模式:
1、当一个方法的传入参数将成为分支语句的判断条件时;
2、当每一个分支的职责相对独立,且逻辑较为复杂时;
3、当分支条件存在扩展的可能时。
 
至于职责链模式的最佳实践,则包含以下内容:
1、应尽量将职责链模式的抽象定义为抽象类,而不要定义为接口。这样有利于一些公共逻辑的重用。
2、应在实现职责链模式的同时,提供创建职责链的工厂类。

本文已在IT168发表:http://tech.it168.com/msoft/2008-01-31/200801310937911.shtml
posted @ 2008-02-17 16:48  张逸  阅读(6717)  评论(20编辑  收藏  举报