facade思想总结

Facade模式的描述：

意图:

为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

适用性:

当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。

客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。

 

当你需要构建一个层次结构的子系统时，使用Facade模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过Facade进行通讯，从而简化了它们之间的依赖关系。

结构图：

总结：

在实际应用中，确实遇到业务逻辑比较复杂的情况。业务逻辑复杂的结果势必导致业务逻辑层极为复杂。复杂的业务逻辑层不仅仅本身由于过于复杂而容易出错。而且它的复杂性也会影响以后对业务逻辑层的修改和维护以及效率。微软duwamish示例代码便引入了facade思想来解决这么一个问题。

微软的做法是将业务逻辑层分开，分别建立facade层和rule层。由rule层来封装一些元素性的业务逻辑规则，而facade层则起到了一个视图和控制器的作用。来自web的请求不能直接访问rule层，而必须访问facade层，由facade层来根据请求决定是访问rule层还是数据层。实际上facade层就是在rule层的基础上抽象出来的一些业务逻辑比较固定，有具体表象的逻辑，象视图一样建立起来。当web层发出请求后，facade层首先判断请求的内容，如果自身能够处理就直接调用数据层。如果自身的业务逻辑不够，则访问rule层，由rule层来访问数据层。

实际上facade这种方法说白了就是在纵向上对一个复杂的系统进行抽象，抽象的结果就是使复杂系统模块化，从而降低每个模块的复杂度。当我想纵向抽象也许会有限制，有时候也许对一个系统无法进行足够的纵向抽象。可不可以对系统进行横向抽象，直接将业务逻辑层根据业务逻辑抽象为好几个模块，然后写一个总的业务逻辑调用层，直接调用业务逻辑的模块，从而实现抽象。我想这种设计应该不是很难，将纵向和横向抽象结合起来，相信这样设计的一个逻辑层可以更加好用。也许吧，没有试验过，也不知道会碰到啥问题。