第二次对外观做出理解，第一次总结为《机房（个人重构）——外观模式》，第一次的总结没有任何问题，不过在合作中对它有了另一层次的认识。

为形成对比，我还以之前上下机为例子：

【1】之前类图：

以及实现代码：

Imports Entity  
Imports BLL  
''' <summary>  
'''  该类用于在上机时，检查卡号是否存在，是否注销，余额是否大于最小限度，  
'''   
''' </summary>  
''' <remarks></remarks>  
Public Class FacCheckCard  
    Public Function CheckCard(enStudent As Entity.StudentEntity) As Boolean  
        Dim enBasicData As New Entity.BasicDataEntity  
        Dim limitMoney As New BLL.SetBasicDataBLL()  
        Dim check As New BLL.PublicBLL()  
        Dim isOnline As New BLL.QueryRecordBLL()  
        Dim mylistData As List(Of BasicDataEntity)  
        Dim isRight As Boolean  
        Dim mylist As List(Of StudentEntity)  
        Dim enOnline As New Entity.OnlineEntity  
        isRight = check.CheckCard(enStudent)  
        If isRight = True Then '如果该卡号存在  
            isRight = check.CheckStatus(enStudent)  
            If isRight = True Then '如果该卡号没有注销  
                mylist = check.CheckBalance(enStudent)  
                mylistData = limitMoney.DataRecord(enBasicData)  
                If Int(mylist(0).balance) < Int(mylistData(0).limitMoney) Then '判断上机余额是否大于最低限额  
                    MsgBox("余额小于最少上机余额" & Trim(mylistData(0).limitMoney) & "元")  
                    Return False  
                    Exit Function  
                Else  
                    Return True  
                End If  
            Else  
                MsgBox("该卡号已经注销！核实后再上机")  
                Return False  
                Exit Function  
            End If  
        Else  
            MsgBox("该卡号不存在，请核实后再上机")  
            Return False  
            Exit Function  
        End If  
  
    End Function  
End Class  

就之前的外观模式分析，这样没有任何问题，而且外观的确达到了隔离系统功能的提供者和使用者，还就此例说明：使用者要下机，而在下机的整个过程中，first，判断卡号是否存在，second，判断卡号是否注销，third，判断该卡号是否正在上机，就这三个功能而言，在功能的提供者也就是BLL层中分别对应三个方法，为隔离UI和BLL层，加入外观层的一个类，在这个具体方法中封装了三个方法，只是三个方法并没有在B层进行进一步的判断，而是直接返回初始结果，在外观层中对业务逻辑层的每一个方法的返回结果进行了判断，这也就是业务逻辑放到了外观。

如此之来，外观用上了，作用也达到了，可是出现一个问题：在B层差不多只进行了return类似的语句，相应的逻辑判断几乎没有，这些工作都交给了外观层来解决，而当初加入外观层的目的是用来解耦的，而解耦的最好方法就是接口，而这里外观提供的好像并不是一个接口，而是类似于B层的一个类，用了外观，反而把B层给架空了，这样的感觉就好像外观层在直接调用数据访问层。

所以，重点问题在外观固然要存在，但是外观的存在的意义要着实分清，其不应含过多的业务逻辑，只是简单的对B层方法进行封装，真正的效果应该是这样的。（在网上当的例子）

【2】在外观层不加业务逻辑的类图：

简单说明一下，这是一个买药的过程，包括（挂号，付钱，取药）三部曲。

转换成代码表示：

外观层：

BLL层：

这样的表示方法好像更符合一些外观存在的实际作用。

外观层的目的，是隔离系统功能的提供者和使用者，更明确的说，是隔离业务逻辑的软件用户界面，这一层没有任何需要处理的逻辑，只是作为后台逻辑处理和前端用户界面的缓冲区，它虽然没有实现任何逻辑，但是，它的引入，能使系统更加有条理，更加简明。

针对外观模式，每个人都有每个人的理解，我想，最好的学习就是一次次不断的实践，应用到实际项目当中。或许我的理解还有所欠缺，还望读者斧正！