移动互联网开发考研方向,网络计划的优化,网站验证码体验,在英特尔上建设网站可选择的方案有概述 在软件开发系统中#xff0c;客户程序经常会与复杂系统的内部子系统之间产生耦合#xff0c;而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口#xff1f;如何将复杂系统的内部子系统与客户程序之间的依赖解耦#xff1f;这就是要说…概述 在软件开发系统中客户程序经常会与复杂系统的内部子系统之间产生耦合而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口如何将复杂系统的内部子系统与客户程序之间的依赖解耦这就是要说的Façade 模式。 意图 为子系统中的一组接口提供一个一致的界面Facade模式定义了一个高层接口这个接口使得这一子系统更加容易使用。[GOF 《设计模式》] 示意图 门面模式没有一个一般化的类图描述下面是一个示意性的对象图 图1 Façade模式示意性对象图 生活中的例子 外观模式为子系统中的接口定义了一个统一的更高层次的界面以便于使用。当消费者按照目录采购时则体现了一个外观模式。消费者拨打一个号码与客服代表联系客服代表则扮演了这个外观他包含了与订货部、收银部和送货部的接口。 图2使用电话订货例子的外观模式对象图 Facade模式解说 我们平时的开发中其实已经不知不觉的在用Façade模式现在来考虑这样一个抵押系统当有一个客户来时有如下几件事情需要确认到银行子系统查询他是否有足够多的存款到信用子系统查询他是否有良好的信用到贷款子系统查询他有无贷款劣迹。只有这三个子系统都通过时才可进行抵押。我们先不考虑Façade模式那么客户程序就要直接访问这些子系统分别进行判断。类结构图下 图3 在这个程序中我们首先要有一个顾客类它是一个纯数据类并无任何操作示意代码 //顾客类public classCustomer{ private string _name; public Customer(string name) { this._name name; } public string Name { get { return _name; } }} 下面这三个类均是子系统类示意代码 //银行子系统public classBank{ public bool HasSufficientSavings(Customer c, int amount) { Console.WriteLine(Check bank for c.Name); return true; }}//信用子系统public classCredit{ public bool HasGoodCredit(Customer c) { Console.WriteLine(Check credit for c.Name); return true; }}//贷款子系统public classLoan{ public bool HasNoBadLoans(Customer c) { Console.WriteLine(Check loans for c.Name); return true; }} 来看客户程序的调用 //客户程序public classMainApp{ private const int _amount 12000; public static void Main() { Bank bank new Bank(); Loan loan new Loan(); Credit credit new Credit(); Customer customer new Customer(Ann McKinsey); bool eligible true; if (!bank.HasSufficientSavings(customer, _amount)) { eligible false; } else if (!loan.HasNoBadLoans(customer)) { eligible false; } else if (!credit.HasGoodCredit(customer)) { eligible false; } Console.WriteLine(\n customer.Name has been (eligible ? Approved : Rejected)); Console.ReadLine(); }} 可以看到在不用Façade模式的情况下客户程序与三个子系统都发生了耦合这种耦合使得客户程序依赖于子系统当子系统变化时客户程序也将面临很多变化的挑战。一个合情合理的设计就是为这些子系统创建一个统一的接口这个接口简化了客户程序的判断操作。看一下引入Façade模式后的类结构图 图4 门面类Mortage的实现如下 //外观类public classMortgage{ private Bank bank new Bank(); private Loan loan new Loan(); private Credit credit new Credit(); public bool IsEligible(Customer cust, int amount) { Console.WriteLine({0} applies for {1:C} loan\n, cust.Name, amount); bool eligible true; if (!bank.HasSufficientSavings(cust, amount)) { eligible false; } else if (!loan.HasNoBadLoans(cust)) { eligible false; } else if (!credit.HasGoodCredit(cust)) { eligible false; } return eligible; }} 顾客类和子系统类的实现仍然如下 //银行子系统public classBank{ public bool HasSufficientSavings(Customer c, int amount) { Console.WriteLine(Check bank for c.Name); return true; }}//信用证子系统public classCredit{ public bool HasGoodCredit(Customer c) { Console.WriteLine(Check credit for c.Name); return true; }}//贷款子系统public classLoan{ public bool HasNoBadLoans(Customer c) { Console.WriteLine(Check loans for c.Name); return true; }}//顾客类public classCustomer{ private string name; public Customer(string name) { this.name name; } public string Name { get { return name; } }} 而此时客户程序的实现 //客户程序类public classMainApp{ public static void Main() { //外观 Mortgage mortgage new Mortgage(); Customer customer new Customer(Ann McKinsey); bool eligable mortgage.IsEligible(customer, 125000); Console.WriteLine(\n customer.Name has been (eligable ? Approved : Rejected)); Console.ReadLine(); }} 可以看到引入Façade模式后客户程序只与Mortgage发生依赖也就是Mortgage屏蔽了子系统之间的复杂的操作达到了解耦内部子系统与客户程序之间的依赖。 .NET架构中的Façade模式 Façade模式在实际开发中最多的运用当属开发N层架构的应用程序了一个典型的N层结构如下 图5 在这个架构中总共分为四个逻辑层分别为用户层UI业务外观层Business Façade业务规则层Business Rule数据访问层Data Access。其中Business Façade层的职责如下 l 从“用户”层接收用户输入 l 如果请求需要对数据进行只读访问则可能使用“数据访问”层 l 将请求传递到“业务规则”层 l 将响应从“业务规则”层返回到“用户”层 l 在对“业务规则”层的调用之间维护临时状态 对这一架构最好的体现就是Duwamish示例了。在该应用程序中有部分操作只是简单的从数据库根据条件提取数据不需要经过任何处理而直接将数据显示到网页上比如查询某类别的图书列表。而另外一些操作比如计算定单中图书的总价并根据顾客的级别计算回扣等等这部分往往有许多不同的功能的类操作起来也比较复杂。如果采用传统的三层结构这些商业逻辑一般是会放在中间层那么对内部的这些大量种类繁多使用方法也各异的不同的类的调用任务就完全落到了表示层。这样势必会增加表示层的代码量将表示层的任务复杂化和表示层只负责接受用户的输入并返回结果的任务不太相称并增加了层与层之间的耦合程度。于是就引入了一个Façade层让这个Facade来负责管理系统内部类的调用并为表示层提供了一个单一而简单的接口。看一下Duwamish结构图 图6 从图中可以看到UI层将请求发送给业务外观层业务外观层对请求进行初步的处理判断是否需要调用业务规则层还是直接调用数据访问层获取数据。最后由数据访问层访问数据库并按照来时的步骤返回结果到UI层来看具体的代码实现。 在获取商品目录的时候Web UI调用业务外观层 productSystem newProductSystem();categorySet productSystem.GetCategories(categoryID); 业务外观层直接调用了数据访问层 publicCategoryData GetCategories(intcategoryId){ // // Check preconditions // ApplicationAssert.CheckCondition(categoryId 0,Invalid Category Id,ApplicationAssert.LineNumber); // // Retrieve the data // using (Categories accessCategories new Categories()) { return accessCategories.GetCategories(categoryId); } } 在添加订单时UI调用业务外观层 public voidAddOrder(){ ApplicationAssert.CheckCondition(cartOrderData ! null, Order requires data, ApplicationAssert.LineNumber); //Write trace log. ApplicationLog.WriteTrace(Duwamish7.Web.Cart.AddOrder:\r\nCustomerId: cartOrderData.Tables[OrderData.CUSTOMER_TABLE].Rows[0][OrderData.PKID_FIELD].ToString()); cartOrderData (new OrderSystem()).AddOrder(cartOrderData);} 业务外观层调用业务规则层 publicOrderData AddOrder(OrderData order){ // // Check preconditions // ApplicationAssert.CheckCondition(order ! null, Order is required, ApplicationAssert.LineNumber); (new BusinessRules.Order()).InsertOrder(order); return order;} 业务规则层进行复杂的逻辑处理后再调用数据访问层 public boolInsertOrder(OrderData order){ // // Assume its good // bool isValid true; // // Validate order summary // DataRow summaryRow order.Tables[OrderData.ORDER_SUMMARY_TABLE].Rows[0]; summaryRow.ClearErrors(); if (CalculateShipping(order) ! (Decimal)(summaryRow[OrderData.SHIPPING_HANDLING_FIELD])) { summaryRow.SetColumnError(OrderData.SHIPPING_HANDLING_FIELD, OrderData.INVALID_FIELD); isValid false; } if (CalculateTax(order) ! (Decimal)(summaryRow[OrderData.TAX_FIELD])) { summaryRow.SetColumnError(OrderData.TAX_FIELD, OrderData.INVALID_FIELD); isValid false; } // // Validate shipping info // isValid IsValidField(order, OrderData.SHIPPING_ADDRESS_TABLE, OrderData.SHIP_TO_NAME_FIELD, 40); // // Validate payment info // DataRow paymentRow order.Tables[OrderData.PAYMENT_TABLE].Rows[0]; paymentRow.ClearErrors(); isValid IsValidField(paymentRow, OrderData.CREDIT_CARD_TYPE_FIELD, 40); isValid IsValidField(paymentRow, OrderData.CREDIT_CARD_NUMBER_FIELD, 32); isValid IsValidField(paymentRow, OrderData.EXPIRATION_DATE_FIELD, 30); isValid IsValidField(paymentRow, OrderData.NAME_ON_CARD_FIELD, 40); isValid IsValidField(paymentRow, OrderData.BILLING_ADDRESS_FIELD, 255); // // Validate the order items and recalculate the subtotal // DataRowCollection itemRows order.Tables[OrderData.ORDER_ITEMS_TABLE].Rows; Decimal subTotal 0; foreach (DataRow itemRow in itemRows) { itemRow.ClearErrors(); subTotal (Decimal)(itemRow[OrderData.EXTENDED_FIELD]); if ((Decimal)(itemRow[OrderData.PRICE_FIELD]) 0) { itemRow.SetColumnError(OrderData.PRICE_FIELD, OrderData.INVALID_FIELD); isValid false; } if ((short)(itemRow[OrderData.QUANTITY_FIELD]) 0) { itemRow.SetColumnError(OrderData.QUANTITY_FIELD, OrderData.INVALID_FIELD); isValid false; } } // // Verify the subtotal // if (subTotal ! (Decimal)(summaryRow[OrderData.SUB_TOTAL_FIELD])) { summaryRow.SetColumnError(OrderData.SUB_TOTAL_FIELD, OrderData.INVALID_FIELD); isValid false; } if ( isValid ) { using (DataAccess.Orders ordersDataAccess new DataAccess.Orders()) { return (ordersDataAccess.InsertOrderDetail(order)) 0; } } else return false;} [MSDN] 效果及实现要点 1Façade模式对客户屏蔽了子系统组件因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。 2Façade模式实现了子系统与客户之间的松耦合关系而子系统内部的功能组件往往是紧耦合的。松耦合关系使得子系统的组件变化不会影响到它的客户。 3如果应用需要它并不限制它们使用子系统类。因此你可以在系统易用性与通用性之间选择。 适用性 1为一个复杂子系统提供一个简单接口。 2提高子系统的独立性。 3在层次化结构中可以使用Facade模式定义系统中每一层的入口。 总结 Façade模式注重的是简化接口它更多的时候是从架构的层次去看整个系统而并非单个类的层次。 转载于:https://www.cnblogs.com/whitetiger/archive/2007/03/31/694814.html
