面向接口编程之三——模式研究

原文链接:http://kb.cnblogs.com/page/145705/

      通过前面两篇,我想各位朋友对“面向接口编程”的思想有了一定认识,并通过第二篇的例子,获得了一定的直观印象。但是,第二篇中的例子旨在展示面向接口编程的实现方法,比较简单,不能体现出面向接口编程的优势和这种思想的内涵。那么,这一篇作为本系列的终结篇,将通过分析几个比较有深度的模式或架构,解析隐藏其背后的面向接口思想。这篇我将要分析的分别是MVC模式和.NET平台的分层架构。

  这篇的内容可能会比较抽象,望谅解。

  1. 从MVC开始

  MVC简介:

  本文不打算详细解释MVC架构,而是把重点放在其中的面向接口思想上。所以在这里,只对MVC做一个简略的介绍。

  MVC是一种用于表示层设计的复合设计模式。M、V、C分别表示模型(Model)、View(视图)、Controller(控制器)。它们的职责如下:

  模型:用于存储应用中的数据及运行逻辑,是应用的实体。

  视图:负责可视部分,用于与用户交互及呈现数据。视图只负责显示,不负责将用户的操作行为解释给模型。

  控制器:负责将用户的行为解释给模型。根据指定的策略和用户的操作,调用模型的逻辑。

  关于三者的关系,我画了一张图,大家请看:

          

                                                    MVC模式示意

  它们之间的交互有以下几种:

  1. 当用户在视图上做任何需要调用模型的操作时,它的请求将被控制器截获。

  2. 控制器按照自身指定的策略,将用户行为翻译成模型操作,调用模型相应逻辑实现。

  3. 控制器可能会在接到视图操作时,指定视图做某些改变。

  4. 当模型的状态发生改变时,将通过某种方式通知视图。

  5. 视图可以从模型获取状态,从而改变自己的显示。

  MVC介绍完了,那么可能会有人问,我们的主题呢?面向接口思想呢?其实,MVC中处处都存在面向接口的影子。下面,我对其中几个侧面进行解释。

  1. 首先我们可以看到,视图和模型是有直接交互的,也就是上面的4、5两点。但是有一点可能会让你吃惊:它们两个谁也不“认识”谁,即它们相互并不知道对方是做什么的、有什么属性、有什么方法,但是它们能交互。这是怎么做到的呢?因为它们个各知道对方实现了某一个接口。

  此乃面向接口思想一大作用:使相互不认识的类进行交互。这样做是很有好处的,首先它们之间的耦合度大大降低,其次双方都可以进行替换,只要实现了相同的接口,就没有问题。

  打个不太恰当的比喻。我们都知道120这个电话号码,是急救电话。其实120就是个接口,因为当你拨打这个电话时,你不知道那边是哪所医院,甚至不知道那边是不是医院,你只知道电话那头的地方可以救人,也可以说实现了IHelp接口。这样,你通过一个号码可以说同全部的救人机构联系起来了,当有紧急事件,接线控制那边会将你的请求接到最近可用的机构,你就可以最快的得到帮助。

  现在我们假设没有使用面向接口思想,来看看会发生什么恐怖的事情:首先,我家的120号码是绑定在本市第一人民医院的,即当我拨打120时,只能拨通第一人民医院。如果有一天我食物中毒了,急忙拨通了120,但是电话那边告诉我他们医院的救护车都派出去了,我问那怎么接通别家医院的电话,那边的MM很温柔的告诉我,让我打电话给网通公司,然后重新为我布线。于是我吐血而亡……

  言归正传。这里,我要引入一个设计模式,叫观察着(Observer)模式。这个模式大约是这样的:整个模式中有两种实体:观察者和被观察者,它们分别实现一个接口,这里我们姑且叫做IObserver与IObserverSubject。IObserver只有一个方法,例如叫Update,当被观察者状态改变时,调用这个方法,用来通知观察者。IObserverSubject接口有两个方法,都是供观察者调用。一个用来将观察者注册为此被观察者的观察对象,另一个用于将观察者移除。

  一般情况下,一个被观察者对应多个观察者。

  在MVC中,视图是观察者,模型是被观察者,当模型状态改变时,调用所有观察者的Update方法,通知视图模型有变,视图在Update方法里写下响应代码,完成操作。通过这个方法,视图和模型就可以在仅依赖接口的情形下进行交互,而不必强耦合,而且在模型不变的情况下,视图可以随意替换。(只要实现了IObserver)

  2. 在MVC中另一个使用接口的地方就是控制器,这里我要首先引入一个设计模式:策略模式(Strategy)。在MVC中,控制器就使用了这个模式。

  刚才我说过,视图负责与用户交互,但是,它只负责界面显示部分,至于当用户做了某个操作(如单击某个按钮)后系统应该怎么反应,视图并不负责,它只是将这个动作交给控制器,控制器根据内置的策略,将用户操作翻译成模型的逻辑。这就是说,同一个视图、同一种操作,模型可以做出不同的反应,这取决与控制器的内置策略。所以,我们的系统中可以有很多控制器,它们有不同的策略,当视图希望改变策略时,它可以更换控制器。怎么实现呢?这就需要视图不能和具体控制器耦合,而是要仅依赖一个控制器接口(如IController),并聚合一个IController的实例。当希望更改策略时,可以在系统运行时动态更换Controller,这就是策略模式的实现。

  关于MVC的接口思想就先介绍到这里。其实MVC中还有很多地方用到面向接口,由于本文不是专门介绍MVC或设计模式的,所以对用到的模式没有做详解,而是把重点放在其中的面向接口思想上。如果没有设计模式的基础,读上文可能会有些困难,希望各位见谅!我打算在以后专门写文章来解析MVC。

  2. .NET平台下分层架构的面向接口思想

  我们知道,在做大一点的系统应用时(特别是B/S架构),比较好的方法是分层架构。所谓分层架构,是指将系统从职责上分成若干层,每层各司其职,上层依赖下层完成操作。

  在.NET平台上,比较经典的分层架构是三层架构,从下到上依次是:数据访问层、业务逻辑层、表示层。各层职责如下:

  数据访问层:负责与数据源交互,完成数据访问等一系列操作。

  业务逻辑层:完成与系统业务有关的逻辑操作。

  表示层:负责与用户交互、呈现数据等一切与系统表示有关的操作。

  刚才我们说过,分层架构下是向下依赖的(不考虑依赖倒置),也就是业务逻辑层要调用数据访问层完成与数据源有关的操作,而表示层调用业务逻辑层完成业务逻辑工作。但是,表示层对数据访问层是没有依赖的。

  在这个架构中,每一层都不是一个类,而是一个类族,例如,在一个CMS系统中,数据访问层可能会有一系列的类,分别负责用户、文章、评论等业务实体的数据访问操作,而业务逻辑层也一样。如果我们直接依赖,即业务逻辑层实例化数据访问层的类,表示层再实例化业务逻辑层的类,会造成强耦合。如果我想把数据库从SQLServer换成MySQL,则要改变整个业务逻辑层代码,这是个不好的设计。(还记得“开放-关闭”原则吗)所以,一般的做法是,为数据访问层和业务逻辑层分别定义一族接口,业务逻辑层不依赖具体的数据访问层,而是仅依赖数据访问层的接口族,表示层也一样,依赖业务逻辑层的接口族。如此一来,当要更换数据库时,我们就不必改写整个业务逻辑层,因为业务逻辑层里根本没有任何数据访问层中的具体类,而全是通过接口实现的。在.NET中,只要配合配置文件和反射机制,再运用Abstract Factory设计模式,就可以实现“依赖注入”,即在不改动代码的情况下根据配置选择相应的层次组件。这样,我们就可以为不通数据库分别实现数据访问层,也可以编写ORM的数据访问层,甚至是基于XML的,只要实现了数据访问层接口族,就可以和业务逻辑层无缝连接,从而极大提高了软件的灵活性和可维护性。当然要更改业务逻辑层也是一样。

  如果说,前面的例子都是从微观视角讨论接口,那么,这个例子则从宏观视角展现了面向接口编程的内涵和优势。很抱歉在这里不能对这个架构深入讲解,有兴趣的朋友可以参考微软的官方示例.NET PetShop4。(但是请注意,这个示例中业务逻辑层没有定义接口族,而是强耦合于表示层中,这可能是因为考虑到在这个系统中业务逻辑没有更改的可能。另外由于是个示例,不是真正的B2C系统,所以业务逻辑层很简单。)

  好了,本系列文章就到这里。希望各位朋友通过这三篇文章,能对“面向接口编程”有一定的了解。当然,我只是起到一个抛砖引玉的作用,其真正的内涵和精髓,还需要各位从实践中慢慢认识。还有,就是面向接口思想不是孤立的,它和设计模式等内容都是面向对象大系中的精华,而且是相互渗透、相互联系的。其实,很多设计模式就是面向接口思想的体现。我们应该把这些放在一起学习,从而真正提供自己的面向对象思考能力和实战能力。

posted @ 2016-06-15 17:15  Tony-Tse  阅读(228)  评论(0编辑  收藏  举报