ITPub博客

首页 > 应用开发 > IT综合 > 设计模式:外观模式

设计模式:外观模式

IT综合 作者:dongyu2013 时间:2014-03-28 19:45:50 0 删除 编辑

动机(Motivate):
    在软件开发系统中,客户程序经常会与复杂系统的内部子系统之间产生耦合,而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口?如何将复杂系统的内部子系统与客户程序之间的依赖解耦?
意图(Intent):
    为子系统中的一组接口提供一个一致的界面, Facade 模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
                                                                         --------《设计模式》GOF
结构图(Struct):
                
                 
            
适用性:

    1 .为一个复杂子系统提供一个简单接口。
    2 .提高子系统的独立性。

    3 .在层次化结构中,可以使用 Facade 模式定义系统中每一层的入口。
生活中的例子: 
                 
代码实现: 
    我们平时的开发中其实已经不知不觉的在用 Fa?ade 模式,现在来考虑这样一个抵押系统,当有一个客户来时,有如下几件事情需要确认:到银行子系统查询他是否有足够多的存款,到信用子系统查询他是否有良好的信用,到贷款子系统查询他有无贷款劣迹。只有这三个子系统都通过时才可进行抵押。我们先不考虑 Fa?ade 模式,那么客户程序就要直接访问这些子系统,分别进行判断。类结构图下: 
                  
    
在这个程序中,我们首先要有一个顾客类,它是一个纯数据类,并无任何操作,示意代码:

 1  // 顾客类 
 2  public  class  Customer
 3  {
 4       private  string  _name;
 5  
 6       public  Customer( string  name)
 7      {
 8           this ._name  =  name;
 9      }
10  
11       public  string  Name
12      {
13           get  {  return  _name; }
14      }
15  }


下面这三个类均是子系统类,示意代码:

 1  // 银行子系统 
 2  public  class  Bank
 3  {
 4       public  bool  HasSufficientSavings(Customer c,  int  amount)
 5      {
 6          Console.WriteLine( " Check bank for  "  +  c.Name);
 7           return  true ;
 8      }
 9  }
10  
11  // 信用子系统 
12  public  class  Credit
13  {
14       public  bool  HasGoodCredit(Customer c)
15      {
16          Console.WriteLine( " Check credit for  "  +  c.Name);
17           return  true ;
18      }
19  }
20  
21  // 贷款子系统 
22  public  class  Loan
23  {
24       public  bool  HasNoBadLoans(Customer c)
25      {
26          Console.WriteLine( " Check loans for  "  +  c.Name);
27           return  true ;
28      }
29  }


看客户程序的调用:

 1  // 客户程序 
 2  public  class  MainApp
 3  {
 4       private  const  int  _amount  =  12000 ;
 5  
 6       public  static  void  Main()
 7      {
 8          Bank bank  =  new  Bank();
 9          Loan loan  =  new  Loan();
10          Credit credit  =  new  Credit();
11  
12          Customer customer  =  new  Customer( " Ann McKinsey " );
13  
14           bool  eligible  =  true ;
15  
16           if  ( ! bank.HasSufficientSavings(customer, _amount))
17          {
18              eligible  =  false ;
19          }
20           else  if  ( ! loan.HasNoBadLoans(customer))
21          {
22              eligible  =  false ;
23          }
24           else  if  ( ! credit.HasGoodCredit(customer))
25          {
26              eligible  =  false ;
27          }
28  
29          Console.WriteLine( " /n "  +  customer.Name  +  "  has been  "  +  (eligible  ?  " Approved "  :  " Rejected "));
30          Console.ReadLine();
31      }
32  }


可以看到,在不用Fa?ade 模式的情况下,客户程序与三个子系统都发生了耦合,这种耦合使得客户程序依赖于子系统,当子系统 化时,客户程序也将面临很多变化的挑战。一个合情合理的设计就是为这些子系统创建一个统一的接口,这个接口简化了客户程序的判断操作。看一下引入 Fa?ade 模式后的类结构图: 
            变 

外观类 Mortage 的实现如下:

 1  / 外观类
 2  public  class  Mortgage
 3  {
 4       private  Bank bank  =  new  Bank();
 5       private  Loan loan  =  new  Loan();
 6       private  Credit credit  =  new  Credit();
 7  
 8       public  bool  IsEligible(Customer cust,  int  amount)
 9      {
10          Console.WriteLine( " {0} applies for {1:C} loan/n " ,
11            cust.Name, amount);
12  
13           bool  eligible  =  true ;
14  
15           if  ( ! bank.HasSufficientSavings(cust, amount))
16          {
17              eligible  =  false ;
18          }
19           else  if  ( ! loan.HasNoBadLoans(cust))
20          {
21              eligible  =  false ;
22          }
23           else  if  ( ! credit.HasGoodCredit(cust))
24          {
25              eligible  =  false ;
26          }
27  
28           return  eligible;
29      }
30  }

顾客类和子系统类的实现仍然如下:

 1  // 银行子系统 
 2  public  class  Bank
 3  {
 4       public  bool  HasSufficientSavings(Customer c,  int  amount)
 5      {
 6          Console.WriteLine( " Check bank for  "  +  c.Name);
 7           return  true ;
 8      }
 9  }
10  
11  // 信用证子系统 
12  public  class  Credit
13  {
14       public  bool  HasGoodCredit(Customer c)
15      {
16          Console.WriteLine( " Check credit for  "  +  c.Name);
17           return  true ;
18      }
19  }
20  
21  // 贷款子系统 
22  public  class  Loan
23  {
24       public  bool  HasNoBadLoans(Customer c)
25      {
26          Console.WriteLine( " Check loans for  "  +  c.Name);
27           return  true ;
28      }
29  }
30  
31  // 顾客类 
32  public  class  Customer
33  {
34       private  string  name;
35  
36       public  Customer( string  name)
37      {
38           this .name  =  name;
39      }
40  
41       public  string  Name
42      {
43           get  {  return  name; }
44      }
45  }

而此时客户程序的实现:

 1  // 客户程序类 
 2  public  class  MainApp
 3  {
 4       public  static  void  Main()
 5      {
 6           // 外观 
 7          Mortgage mortgage  =  new  Mortgage();
 8  
 9          Customer customer  =  new  Customer( " Ann McKinsey " );
10           bool  eligable  =  mortgage.IsEligible(customer,  125000 );
11  
12          Console.WriteLine( " /n "  +  customer.Name  + 
13               "  has been  "  +  (eligable  ?  " Approved "  :  " Rejected " )); 
14          Console.ReadLine();
15      }
16  }

可以看到引入Fa?ade 模式后,客户程序只与 Mortgage 发生依赖,也就是 Mortgage 屏蔽了子系统之间的复杂的操作,达到了解耦内部子系统与客户程序之间的依赖。 

.NET 架构中的 Fa?ade 模式


Fa?ade 模式在实际开发中最多的运用当属开发 N 层架构的应用程序了,一个典型的 N 层结构如下:
               

    在这个架构中,总共分为四个逻辑层,分别为:用户层 UI ,业务外观层 Business Fa?ade ,业务规则层 Business Rule ,数据访问层 Data Access 。其中 Business Fa?ade 层的职责如下:
l         从“用户”层接收用户输入
l         如果请求需要对数据进行只读访问,则可能使用“数据访问”层
l         将请求传递到“业务规则”层
l         将响应从“业务规则”层返回到“用户”层
l         在对“业务规则”层的调用之间维护临时状态

对这一架构最好的体现就是 Duwamish 示 例了。在该应用程序中,有部分操作只是简单的从数据库根据条件提取数据,不需要经过任何处理,而直接将数据显示到网页上,比如查询某类别的图书列表。而另 外一些操作,比如计算定单中图书的总价并根据顾客的级别计算回扣等等,这部分往往有许多不同的功能的类,操作起来也比较复杂。如果采用传统的三层结构,这 些商业逻辑一般是会放在中间层,那么对内部的这些大量种类繁多,使用方法也各异的不同的类的调用任务,就完全落到了表示层。这样势必会增加表示层的代码 量,将表示层的任务复杂化,和表示层只负责接受用户的输入并返回结果的任务不太相称,并增加了层与层之间的耦合程度。于是就引入了一个 Fa?ade 层,让这个 Facade 来负责管理系统内部类的调用,并为表示层提供了一个单一 而简单的接口。看一下Duwamish结构图:                                                                        
 

从图中可以看到,UI层 将请求发送给业务外观层,业务外观层对请求进行初步的处理,判断是否需要调用业务规则层,还是直接调用数据访问层获取数据。最后由数据访问层访问数据库并按 照来时的步骤返回结果到 UI 层,来看具体的代码实现。

在获取商品目录的时候, Web UI 调用业务外观层:

1  productSystem  =  new  ProductSystem();
2  categorySet    =  productSystem.GetCategories(categoryID);


业务外观层直接调用了数据访问层:

 1  public  CategoryData GetCategories( int  categoryId)
 2  {
 3       // 
 4       //  Check preconditions
 5       //
 6      ApplicationAssert.CheckCondition(categoryId  >=  0 , " Invalid Category Id " ,ApplicationAssert.LineNumber);
 7       // 
 8       //  Retrieve the data
 9       //
10       using  (Categories accessCategories  =  new  Categories())
11      {
12           return  accessCategories.GetCategories(categoryId);
13      }
14      
15  }


在添加订单时,UI调用业务外观层:

1  public  void  AddOrder()
2  {
3      ApplicationAssert.CheckCondition(cartOrderData  !=  null ,  " Order requires data ", ApplicationAssert.LineNumber);
4  
5       // Write trace log. 
6      ApplicationLog.WriteTrace( " Duwamish7.Web.Cart.AddOrder:/r/nCustomerId:  "  + 
7                                  cartOrderData.Tables[OrderData.CUSTOMER_TABLE].Rows[ 0 ][OrderData.PKID_FIELD].ToString());
8      cartOrderData  =  ( new  OrderSystem()).AddOrder(cartOrderData);
9  }


业务外观层调用业务规则层:

 1  public  OrderData AddOrder(OrderData order)
 2  {
 3       // 
 4       //  Check preconditions
 5       //
 6      ApplicationAssert.CheckCondition(order  !=  null ,  " Order is required " , ApplicationAssert.LineNumber);
 7      
 8      ( new  BusinessRules.Order()).InsertOrder(order);
 9       return  order;
10  }

 


业务规则层进行复杂的逻辑处理后,再调用数据访问层:

 1  public  OrderData AddOrder(OrderData order)
 2  {
 3       // 
 4       //  Check preconditions
 5       //
 6      ApplicationAssert.CheckCondition(order  !=  null ,  " Order is required " , ApplicationAssert.LineNumber);
 7      
 8      ( new  BusinessRules.Order()).InsertOrder(order);
 9       return  order;
10  }
11  
12  
13  业务规则层进行复杂的逻辑处理后,再调用数据访问层:
14  public  bool  InsertOrder(OrderData order)
15  {    
16       // 
17       //  Assume it's good
18       //
19       bool  isValid  =  true ;
20       //             
21       //  Validate order summary
22       //
23      DataRow summaryRow  =  order.Tables[OrderData.ORDER_SUMMARY_TABLE].Rows[ 0 ];
24      
25      summaryRow.ClearErrors();
26  
27       if  (CalculateShipping(order)  !=  (Decimal)(summaryRow[OrderData.SHIPPING_HANDLING_FIELD]))
28      {
29          summaryRow.SetColumnError(OrderData.SHIPPING_HANDLING_FIELD, OrderData.INVALID_FIELD);
30          isValid  =  false ;
31      }
32  
33       if  (CalculateTax(order)  !=  (Decimal)(summaryRow[OrderData.TAX_FIELD]))
34      {
35          summaryRow.SetColumnError(OrderData.TAX_FIELD, OrderData.INVALID_FIELD);
36          isValid  =  false ;
37      }
38       //     
39       //  Validate shipping info
40       //
41      isValid  &= IsValidField(order, OrderData.SHIPPING_ADDRESS_TABLE, OrderData.SHIP_TO_NAME_FIELD,  40 );
42       // 
43       //  Validate payment info 
44       //
45      DataRow paymentRow  =  order.Tables[OrderData.PAYMENT_TABLE].Rows[ 0 ];
46      
47      paymentRow.ClearErrors();
48      
49      isValid  &=  IsValidField(paymentRow, OrderData.CREDIT_CARD_TYPE_FIELD,  40 );
50      isValid  &=  IsValidField(paymentRow, OrderData.CREDIT_CARD_NUMBER_FIELD,   32 );
51      isValid  &=  IsValidField(paymentRow, OrderData.EXPIRATION_DATE_FIELD,  30 );
52      isValid  &=  IsValidField(paymentRow, OrderData.NAME_ON_CARD_FIELD,  40 );
53      isValid  &=  IsValidField(paymentRow, OrderData.BILLING_ADDRESS_FIELD,  255 );
54       // 
55       //  Validate the order items and recalculate the subtotal
56       //
57      DataRowCollection itemRows  =  order.Tables[OrderData.ORDER_ITEMS_TABLE].Rows;
58      
59      Decimal subTotal  =  0 ;
60      
61       foreach  (DataRow itemRow  in  itemRows)
62      {
63          itemRow.ClearErrors();
64          
65          subTotal  +=  (Decimal)(itemRow[OrderData.EXTENDED_FIELD]);
66          
67           if  ((Decimal)(itemRow[OrderData.PRICE_FIELD])  <=  0 )
68          {
69              itemRow.SetColumnError(OrderData.PRICE_FIELD, OrderData.INVALID_FIELD);
70              isValid  =  false ;
71          }
72  
73           if  (( short )(itemRow[OrderData.QUANTITY_FIELD])  <=  0 )
74          {
75              itemRow.SetColumnError(OrderData.QUANTITY_FIELD, OrderData.INVALID_FIELD);
76              isValid  =  false ;
77          }
78      }
79       // 
80       //  Verify the subtotal
81       //
82       if  (subTotal  !=  (Decimal)(summaryRow[OrderData.SUB_TOTAL_FIELD]))
83      {
84          summaryRow.SetColumnError(OrderData.SUB_TOTAL_FIELD, OrderData.INVALID_FIELD);
85          isValid  =  false ;
86      }
87  
88       if  ( isValid )
89      {
90           using  (DataAccess.Orders ordersDataAccess  =  new  DataAccess.Orders())
91          {
92               return  (ordersDataAccess.InsertOrderDetail(order))  >  0 ;
93          }
94      }
95       else 
96           return  false ;
97  }


Facade模式的个要点:
    从客户程序的角度来看,Facade模式不仅简化了整个组件系统的接口,同时对于组件内部与外部客户程序来说,从某种程度上也达到了一种“解耦”的效果----内部子系统的任何变化不会影响到Facade接口的变化。

    Facade设计模式更注重从架构的层次去看整个系统,而不是单个类的层次。Facdae很多时候更是一种架构
设计模式。
    注意区分Facade模式、Adapter模式、Bridge模式与Decorator模式。Facade模式注重简化接口,Adapter模式注重转换 接口,Bridge模式注重分离接口(抽象)与其实现,Decorator模式注重稳定接口的前提下为对象扩展功能。

 

动机(Motivate):
    在软件开发系统中,客户程序经常会与复杂系统的内部子系统之间产生耦合,而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口?如何将复杂系统的内部子系统与客户程序之间的依赖解耦?
意图(Intent):
    为子系统中的一组接口提供一个一致的界面, Facade 模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
                                                                         --------《设计模式》GOF
结构图(Struct):
                
                 
            
适用性:

    1 .为一个复杂子系统提供一个简单接口。
    2 .提高子系统的独立性。

    3 .在层次化结构中,可以使用 Facade 模式定义系统中每一层的入口。
生活中的例子: 
                 
代码实现: 
    我们平时的开发中其实已经不知不觉的在用 Fa?ade 模式,现在来考虑这样一个抵押系统,当有一个客户来时,有如下几件事情需要确认:到银行子系统查询他是否有足够多的存款,到信用子系统查询他是否有良好的信用,到贷款子系统查询他有无贷款劣迹。只有这三个子系统都通过时才可进行抵押。我们先不考虑 Fa?ade 模式,那么客户程序就要直接访问这些子系统,分别进行判断。类结构图下: 
                  
    
在这个程序中,我们首先要有一个顾客类,它是一个纯数据类,并无任何操作,示意代码:

 1  // 顾客类 
 2  public  class  Customer
 3  {
 4       private  string  _name;
 5  
 6       public  Customer( string  name)
 7      {
 8           this ._name  =  name;
 9      }
10  
11       public  string  Name
12      {
13           get  {  return  _name; }
14      }
15  }


下面这三个类均是子系统类,示意代码:

 1  // 银行子系统 
 2  public  class  Bank
 3  {
 4       public  bool  HasSufficientSavings(Customer c,  int  amount)
 5      {
 6          Console.WriteLine( " Check bank for  "  +  c.Name);
 7           return  true ;
 8      }
 9  }
10  
11  // 信用子系统 
12  public  class  Credit
13  {
14       public  bool  HasGoodCredit(Customer c)
15      {
16          Console.WriteLine( " Check credit for  "  +  c.Name);
17           return  true ;
18      }
19  }
20  
21  // 贷款子系统 
22  public  class  Loan
23  {
24       public  bool  HasNoBadLoans(Customer c)
25      {
26          Console.WriteLine( " Check loans for  "  +  c.Name);
27           return  true ;
28      }
29  }


看客户程序的调用:

 1  // 客户程序 
 2  public  class  MainApp
 3  {
 4       private  const  int  _amount  =  12000 ;
 5  
 6       public  static  void  Main()
 7      {
 8          Bank bank  =  new  Bank();
 9          Loan loan  =  new  Loan();
10          Credit credit  =  new  Credit();
11  
12          Customer customer  =  new  Customer( " Ann McKinsey " );
13  
14           bool  eligible  =  true ;
15  
16           if  ( ! bank.HasSufficientSavings(customer, _amount))
17          {
18              eligible  =  false ;
19          }
20           else  if  ( ! loan.HasNoBadLoans(customer))
21          {
22              eligible  =  false ;
23          }
24           else  if  ( ! credit.HasGoodCredit(customer))
25          {
26              eligible  =  false ;
27          }
28  
29          Console.WriteLine( " /n "  +  customer.Name  +  "  has been  "  +  (eligible  ?  " Approved "  :  " Rejected "));
30          Console.ReadLine();
31      }
32  }


可以看到,在不用Fa?ade 模式的情况下,客户程序与三个子系统都发生了耦合,这种耦合使得客户程序依赖于子系统,当子系统 化时,客户程序也将面临很多变化的挑战。一个合情合理的设计就是为这些子系统创建一个统一的接口,这个接口简化了客户程序的判断操作。看一下引入 Fa?ade 模式后的类结构图: 
            变 

外观类 Mortage 的实现如下:

 1  / 外观类
 2  public  class  Mortgage
 3  {
 4       private  Bank bank  =  new  Bank();
 5       private  Loan loan  =  new  Loan();
 6       private  Credit credit  =  new  Credit();
 7  
 8       public  bool  IsEligible(Customer cust,  int  amount)
 9      {
10          Console.WriteLine( " {0} applies for {1:C} loan/n " ,
11            cust.Name, amount);
12  
13           bool  eligible  =  true ;
14  
15           if  ( ! bank.HasSufficientSavings(cust, amount))
16          {
17              eligible  =  false ;
18          }
19           else  if  ( ! loan.HasNoBadLoans(cust))
20          {
21              eligible  =  false ;
22          }
23           else  if  ( ! credit.HasGoodCredit(cust))
24          {
25              eligible  =  false ;
26          }
27  
28           return  eligible;
29      }
30  }

顾客类和子系统类的实现仍然如下:

 1  // 银行子系统 
 2  public  class  Bank
 3  {
 4       public  bool  HasSufficientSavings(Customer c,  int  amount)
 5      {
 6          Console.WriteLine( " Check bank for  "  +  c.Name);
 7           return  true ;
 8      }
 9  }
10  
11  // 信用证子系统 
12  public  class  Credit
13  {
14       public  bool  HasGoodCredit(Customer c)
15      {
16          Console.WriteLine( " Check credit for  "  +  c.Name);
17           return  true ;
18      }
19  }
20  
21  // 贷款子系统 
22  public  class  Loan
23  {
24       public  bool  HasNoBadLoans(Customer c)
25      {
26          Console.WriteLine( " Check loans for  "  +  c.Name);
27           return  true ;
28      }
29  }
30  
31  // 顾客类 
32  public  class  Customer
33  {
34       private  string  name;
35  
36       public  Customer( string  name)
37      {
38           this .name  =  name;
39      }
40  
41       public  string  Name
42      {
43           get  {  return  name; }
44      }
45  }

而此时客户程序的实现:

 1  // 客户程序类 
 2  public  class  MainApp
 3  {
 4       public  static  void  Main()
 5      {
 6           // 外观 
 7          Mortgage mortgage  =  new  Mortgage();
 8  
 9          Customer customer  =  new  Customer( " Ann McKinsey " );
10           bool  eligable  =  mortgage.IsEligible(customer,  125000 );
11  
12          Console.WriteLine( " /n "  +  customer.Name  + 
13               "  has been  "  +  (eligable  ?  " Approved "  :  " Rejected " )); 
14          Console.ReadLine();
15      }
16  }

可以看到引入Fa?ade 模式后,客户程序只与 Mortgage 发生依赖,也就是 Mortgage 屏蔽了子系统之间的复杂的操作,达到了解耦内部子系统与客户程序之间的依赖。 

.NET 架构中的 Fa?ade 模式


Fa?ade 模式在实际开发中最多的运用当属开发 N 层架构的应用程序了,一个典型的 N 层结构如下:
               

    在这个架构中,总共分为四个逻辑层,分别为:用户层 UI ,业务外观层 Business Fa?ade ,业务规则层 Business Rule ,数据访问层 Data Access 。其中 Business Fa?ade 层的职责如下:
l         从“用户”层接收用户输入
l         如果请求需要对数据进行只读访问,则可能使用“数据访问”层
l         将请求传递到“业务规则”层
l         将响应从“业务规则”层返回到“用户”层
l         在对“业务规则”层的调用之间维护临时状态

对这一架构最好的体现就是 Duwamish 示 例了。在该应用程序中,有部分操作只是简单的从数据库根据条件提取数据,不需要经过任何处理,而直接将数据显示到网页上,比如查询某类别的图书列表。而另 外一些操作,比如计算定单中图书的总价并根据顾客的级别计算回扣等等,这部分往往有许多不同的功能的类,操作起来也比较复杂。如果采用传统的三层结构,这 些商业逻辑一般是会放在中间层,那么对内部的这些大量种类繁多,使用方法也各异的不同的类的调用任务,就完全落到了表示层。这样势必会增加表示层的代码 量,将表示层的任务复杂化,和表示层只负责接受用户的输入并返回结果的任务不太相称,并增加了层与层之间的耦合程度。于是就引入了一个 Fa?ade 层,让这个 Facade 来负责管理系统内部类的调用,并为表示层提供了一个单一 而简单的接口。看一下Duwamish结构图:                                                                        
 

从图中可以看到,UI层 将请求发送给业务外观层,业务外观层对请求进行初步的处理,判断是否需要调用业务规则层,还是直接调用数据访问层获取数据。最后由数据访问层访问数据库并按 照来时的步骤返回结果到 UI 层,来看具体的代码实现。

在获取商品目录的时候, Web UI 调用业务外观层:

1  productSystem  =  new  ProductSystem();
2  categorySet    =  productSystem.GetCategories(categoryID);


业务外观层直接调用了数据访问层:

 1  public  CategoryData GetCategories( int  categoryId)
 2  {
 3       // 
 4       //  Check preconditions
 5       //
 6      ApplicationAssert.CheckCondition(categoryId  >=  0 , " Invalid Category Id " ,ApplicationAssert.LineNumber);
 7       // 
 8       //  Retrieve the data
 9       //
10       using  (Categories accessCategories  =  new  Categories())
11      {
12           return  accessCategories.GetCategories(categoryId);
13      }
14      
15  }


在添加订单时,UI调用业务外观层:

1  public  void  AddOrder()
2  {
3      ApplicationAssert.CheckCondition(cartOrderData  !=  null ,  " Order requires data ", ApplicationAssert.LineNumber);
4  
5       // Write trace log. 
6      ApplicationLog.WriteTrace( " Duwamish7.Web.Cart.AddOrder:/r/nCustomerId:  "  + 
7                                  cartOrderData.Tables[OrderData.CUSTOMER_TABLE].Rows[ 0 ][OrderData.PKID_FIELD].ToString());
8      cartOrderData  =  ( new  OrderSystem()).AddOrder(cartOrderData);
9  }


业务外观层调用业务规则层:

 1  public  OrderData AddOrder(OrderData order)
 2  {
 3       // 
 4       //  Check preconditions
 5       //
 6      ApplicationAssert.CheckCondition(order  !=  null ,  " Order is required " , ApplicationAssert.LineNumber);
 7      
 8      ( new  BusinessRules.Order()).InsertOrder(order);
 9       return  order;
10  }

 


业务规则层进行复杂的逻辑处理后,再调用数据访问层:

 1  public  OrderData AddOrder(OrderData order)
 2  {
 3       // 
 4       //  Check preconditions
 5       //
 6      ApplicationAssert.CheckCondition(order  !=  null ,  " Order is required " , ApplicationAssert.LineNumber);
 7      
 8      ( new  BusinessRules.Order()).InsertOrder(order);
 9       return  order;
10  }
11  
12  
13  业务规则层进行复杂的逻辑处理后,再调用数据访问层:
14  public  bool  InsertOrder(OrderData order)
15  {    
16       // 
17       //  Assume it's good
18       //
19       bool  isValid  =  true ;
20       //             
21       //  Validate order summary
22       //
23      DataRow summaryRow  =  order.Tables[OrderData.ORDER_SUMMARY_TABLE].Rows[ 0 ];
24      
25      summaryRow.ClearErrors();
26  
27       if  (CalculateShipping(order)  !=  (Decimal)(summaryRow[OrderData.SHIPPING_HANDLING_FIELD]))
28      {
29          summaryRow.SetColumnError(OrderData.SHIPPING_HANDLING_FIELD, OrderData.INVALID_FIELD);
30          isValid  =  false ;
31      }
32  
33       if  (CalculateTax(order)  !=  (Decimal)(summaryRow[OrderData.TAX_FIELD]))
34      {
35          summaryRow.SetColumnError(OrderData.TAX_FIELD, OrderData.INVALID_FIELD);
36          isValid  =  false ;
37      }
38       //     
39       //  Validate shipping info
40       //
41      isValid  &= IsValidField(order, OrderData.SHIPPING_ADDRESS_TABLE, OrderData.SHIP_TO_NAME_FIELD,  40 );
42       // 
43       //  Validate payment info 
44       //
45      DataRow paymentRow  =  order.Tables[OrderData.PAYMENT_TABLE].Rows[ 0 ];
46      
47      paymentRow.ClearErrors();
48      
49      isValid  &=  IsValidField(paymentRow, OrderData.CREDIT_CARD_TYPE_FIELD,  40 );
50      isValid  &=  IsValidField(paymentRow, OrderData.CREDIT_CARD_NUMBER_FIELD,   32 );
51      isValid  &=  IsValidField(paymentRow, OrderData.EXPIRATION_DATE_FIELD,  30 );
52      isValid  &=  IsValidField(paymentRow, OrderData.NAME_ON_CARD_FIELD,  40 );
53      isValid  &=  IsValidField(paymentRow, OrderData.BILLING_ADDRESS_FIELD,  255 );
54       // 
55       //  Validate the order items and recalculate the subtotal
56       //
57      DataRowCollection itemRows  =  order.Tables[OrderData.ORDER_ITEMS_TABLE].Rows;
58      
59      Decimal subTotal  =  0 ;
60      
61       foreach  (DataRow itemRow  in  itemRows)
62      {
63          itemRow.ClearErrors();
64          
65          subTotal  +=  (Decimal)(itemRow[OrderData.EXTENDED_FIELD]);
66          
67           if  ((Decimal)(itemRow[OrderData.PRICE_FIELD])  <=  0 )
68          {
69              itemRow.SetColumnError(OrderData.PRICE_FIELD, OrderData.INVALID_FIELD);
70              isValid  =  false ;
71          }
72  
73           if  (( short )(itemRow[OrderData.QUANTITY_FIELD])  <=  0 )
74          {
75              itemRow.SetColumnError(OrderData.QUANTITY_FIELD, OrderData.INVALID_FIELD);
76              isValid  =  false ;
77          }
78      }
79       // 
80       //  Verify the subtotal
81       //
82       if  (subTotal  !=  (Decimal)(summaryRow[OrderData.SUB_TOTAL_FIELD]))
83      {
84          summaryRow.SetColumnError(OrderData.SUB_TOTAL_FIELD, OrderData.INVALID_FIELD);
85          isValid  =  false ;
86      }
87  
88       if  ( isValid )
89      {
90           using  (DataAccess.Orders ordersDataAccess  =  new  DataAccess.Orders())
91          {
92               return  (ordersDataAccess.InsertOrderDetail(order))  >  0 ;
93          }
94      }
95       else 
96           return  false ;
97  }


Facade模式的个要点:
    从客户程序的角度来看,Facade模式不仅简化了整个组件系统的接口,同时对于组件内部与外部客户程序来说,从某种程度上也达到了一种“解耦”的效果----内部子系统的任何变化不会影响到Facade接口的变化。

    Facade设计模式更注重从架构的层次去看整个系统,而不是单个类的层次。Facdae很多时候更是一种架构
设计模式。
    注意区分Facade模式、Adapter模式、Bridge模式与Decorator模式。Facade模式注重简化接口,Adapter模式注重转换 接口,Bridge模式注重分离接口(抽象)与其实现,Decorator模式注重稳定接口的前提下为对象扩展功能。

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29012686/viewspace-1131852/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2013-12-25

  • 博文量
    263
  • 访问量
    209351