// 顾客类
public   class  Customer
{
    private string _name;

    public Customer(string name)
    {
        this._name = name;
    }

    public string Name
    {
        get { return _name; }
    }
}

下面这三个类均是子系统类，示意代码：

// 银行子系统
public   class  Bank
{
    public bool HasSufficientSavings(Customer c, int amount)
    {
        Console.WriteLine("Check bank for " + c.Name);
        return true;
    }
}

// 信用子系统
public   class  Credit
{
    public bool HasGoodCredit(Customer c)
    {
        Console.WriteLine("Check credit for " + c.Name);
        return true;
    }
}

// 贷款子系统
public   class  Loan
{
    public bool HasNoBadLoans(Customer c)
    {
        Console.WriteLine("Check loans for " + c.Name);
        return true;
    }
}

来看客户程序的调用：

// 客户程序
public   class  MainApp
{
    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   class  Mortgage
{
    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   class  Bank
{
    public bool HasSufficientSavings(Customer c, int amount)
    {
        Console.WriteLine("Check bank for " + c.Name);
        return true;
    }
}

// 信用证子系统
public   class  Credit
{
    public bool HasGoodCredit(Customer c)
    {
        Console.WriteLine("Check credit for " + c.Name);
        return true;
    }
}

// 贷款子系统
public   class  Loan
{
    public bool HasNoBadLoans(Customer c)
    {
        Console.WriteLine("Check loans for " + c.Name);
        return true;
    }
}

// 顾客类
public   class  Customer
{
    private string name;

    public Customer(string name)
    {
        this.name = name;
    }

    public string Name
    {
        get { return name; }
    }
}

而此时客户程序的实现：

// 客户程序类
public   class  MainApp
{
    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 调用业务外观层：