您的位置:知识库 »

.NET初学者架构设计指南(四)Model-View-Controller

作者: 小陆  来源: 博客园  发布时间: 2008-09-10 14:38  阅读: 8885 次  推荐: 0   原文链接   [收藏]  

系列文章导航:

.NET初学者架构设计指南(一)Hello world的时代

.NET初学者架构设计指南(二)OO设计初次见面

.NET初学者架构设计指南(三)设计模式

.NET初学者架构设计指南(四)Model-View-Controller


  Model-View-Controller简称为MVC,这是图形界面(GUI)应用程序的一种架构形式。Model是业务领域层,比如我们在前面两篇里面提到的Account、Entry、Bill、Invoice之类的对象,这些类构成了一个电信账务系统的业务领域层;View就是用户界面;Controller是指用户界面和业务对象之间的控制器,控制器的作用是从业务对象中获取数据显示到用户界面上,并且从界面上收集用户的输入和动作,然后调用业务对象完成业务功能。

 

  大部分软件系统的工作可以总结成下面这样的流程:从存储数据的地方取得数据,把他们显示在用户界面上,然后用户在界面上修改这些数据,再把数据写回存储。数据在存储和界面之间来回流动。这种看似简单的分析方式经常让开发者有这样一种冲动:把界面和数据写在一起,这样可以少很多层次,少写很多代码,也可以减少运行过程的环节,似乎可以加快程序的运行效率。但是实际上,这种直来直去的烟囱式系统不能很好的隔离界面和业务代码,在开发和维护的过程中会带来很多麻烦。

 

  把程序的界面和业务代码分离开会带来很多好处。一般的说来,界面比起业务逻辑来变化来的更加频繁一些,修改界面的时候,不应该对业务代码造成影响;开发这两个部分所使用的技巧也有很大的差别;在有些系统里面,需要为同一个功能开发多种界面,比如一个Windows窗体界面给后台管理人员使用,一个Web页界面提供给广大人民群众,还需要做一个适用于PDA浏览器的界面,如果界面和业务代码是混杂在一起的,多种界面的开发就需要做很多重复性的工作;把界面和业务代码分离开也使可以为自动化的单元测试提供很多方便,要对用户界面创建单元测试代码是十分繁杂的,而对业务代码做单元测试则是简单的,也是必要的。

 

  于是有经验的开发者会在设计程序的时候创建一个业务领域层,在这个层次中有很多业务对象,他们直接体现了业务需求的核心。用户界面层不是自己实现业务功能,而是调用后台的业务对象。用户界面向用户展示业务对象的属性,并且捕获用户的输入,调用业务对象的方法实现各种功能需求。当业务逻辑层和用户界面层都具备了以后,剩下的一个问题就是:如何把这两个层次粘和起来——这就是控制器需要做的工作。

 

  最简单的控制方式就是直接在界面中调用业务对象,这种方式称为Model-View模式。

  Model-View模式在界面和业务模型之间建立了一种最简单的依赖关系,界面直接调用业务模型,模型通过消息这样的松耦合方式修改界面上的表示内容(比如上一篇里面使用C#语言中的事件实现告警在界面上的显示)。这样可以实现层次的分离,对改善软件系统的构架是有一定的帮助的。

 

  使用过Microsoft Visual Studio各个版本的开发者一定对Model-View的控制方式非常熟悉,无是在VB、VC,还是后来的C#、ASP.NET中,我们把一个按钮控件拖放到窗体上,然后鼠标点击这个控件,就会自动生成一段事件响应代码。下面是用这种方式编写的一段程序,这是“非洲电信公司账务系统”的一个界面,营业员使用这个界面为用户缴费:

 

  营业员在“号码”输入框里面填写用户的电话号码,在“金额”输入框里填写需要交的金额,然后点击“提交”按钮,就可以把钱交进账户。如果发生了异常情况,程序会出现提示。

 

  按下“提交”按钮的时候,按钮发出Click事件,窗体可以捕获这个事件,采取响应行动。控制器就是用这样的机制实现的。

Code
0
0

热门文章

    最新文章

      最新新闻

        热门新闻