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 = new ProductSystem(); categorySet = productSystem.GetCategories(categoryID);
在添加订单时,UI调用业务外观层:public CategoryData GetCategories(int categoryId) { // // Check preconditions // ApplicationAssert.CheckCondition(categoryId >= 0,"Invalid Category Id",ApplicationAssert.LineNumber); // // Retrieve the data // using (Categories accessCategories = new Categories()) { return accessCategories.GetCategories(categoryId); } }
业务外观层调用业务规则层:public void AddOrder() { 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); }
public OrderData AddOrder(OrderData order) { // // Check preconditions // ApplicationAssert.CheckCondition(order != null, "Order is required", ApplicationAssert.LineNumber); (new BusinessRules.Order()).InsertOrder(order); return order; }