长沙法律咨询网站设计开发,网站设计欣赏,网站做弹窗广告吗,快速建站用什么1 前言 用户界面#xff0c;特别是图形用户界面#xff0c;承担着向用户显示问题模型和与用户进行操作和I/O交互的作用。用户希望保持交互操作界面的相对稳定#xff0c;但更希 望根据需要改变和调整显示的内容和形式。例如#xff0c;要求支持不同的界面标准或得到不同…1 前言 用户界面特别是图形用户界面承担着向用户显示问题模型和与用户进行操作和I/O交互的作用。用户希望保持交互操作界面的相对稳定但更希 望根据需要改变和调整显示的内容和形式。例如要求支持不同的界面标准或得到不同的显示效果适应不同的操作需求。这就要求界面结构能够在不改变软件的功 能和模型情况下支持用户对界面构成的调整。 要做到这一点从界面构成的角度看困难在于在满足对界面要求的同时如何使软件的计算模型独立于界面的构成。模型-视图-控制MVCModel-View-Controller就是这样的一种交互界面的结构组织模型。 2 MVCModel-View-Control MVC由Trygve Reenskaug提出首先被应用在SmallTalk-80环境中使许多交互和界面系统的构成基础Microsoft的MFC基础类也遵循了MVC的思想。 对于界面设计可变性的需求MVC把交互系统的组成分解成模型、视图、控制三种部件。 模型部件是软件所处理问题逻辑在独立于外在显示内容和形式情况下的内在抽象封装了问题的核心数据、逻辑和功能的计算关系他独立于具体的界面表达和I/O操作。 视图部件把表示模型数据及逻辑关系和状态的信息及特定形式展示给用户。它从模型获得显示信息对于相同的信息可以有多个不同的显示形式或视图。 控制部件是处理用户与软件的交互操作的其职责是控制提供模型中任何变化的传播确保用户界面于模型间的对应联系它接受用户的输入将输入反馈给模型进而实现对模型的计算控制是使模型和视图协调工作的部件。通常一个视图具有一个控制器。 模型、视图与控制器的分离使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据所有其它依赖于这些数据的视 图都应反映到这些变化。因此无论何时发生了何种数据变化控制器都会将变化通知所有的视图导致显示的更新。这实际上是一种模型的变化-传播机制。 2.1 MVC中的模型、视图和控制类 MVC中的模型、视图和控制类如图1所示。 1 模型包含了应用问题的核心数据、逻辑关系和计算功能它封装了所需的数据提供了完成问题处理的操作过程。控制器依据I/O的需要调用这些操作过程。模型还为视图获取显示数据而提供了访问其数据的操作。 这种变化-传播机制体现在各个相互依赖部件之间的注册关系上。模型数据和状态的变化会激发这种变化-传播机制它是模型、视图和控制器之间联系的纽带。 2 视图通过显示的形式把信息转达给用户。不同视图通过不同的显示来表达模型的数据和状态信息。每个视图有一个更新操作它可被变化-传播机制所激活。当调用更新操作时视图获得来自模型的数据值并用它们来更新显示。 在初始化时通过与变化-传播机制的注册关系建立起所有视图与模型间的关联。视图与控制器之间保持着一对一的关系每个视图创建一个相应的控制器。视图提供给控制器处理显示的操作。因此控制器可以获得主动激发界面更新的能力。 3 控制器通过时间触发的方式接受用户的输入。控制器如何获得事件依赖于界面的运行平台。控制器通过事件处理过程对输入事件进行处理并为每个输入事件提供了相应的操作服务把事件转化成对模型或相关视图的激发操作。 如果控制器的行为依赖于模型的状态则控制器应该在变化-传播机制中进行注册并提供一个更新操作。这样可以由模型的变化来改变控制器的行为如禁止某些操作。 3 MVC的实现 实现基于MVC的应用需要完成以下工作如图2所示 3.1 分析应用问题对系统进行分离 分析应用问题分离出系统的内核功能、对功能的控制输入、系统的输出行为三大部分。设计模型部件使其封装内核数据和计算功能提供访问显示数 据的操作提供控制内部行为的操作以及其他必要的操作接口。以上形成模型类的数据构成和计算关系。这部分的构成与具体的应用问题紧密相关。 3.2 设计和实现每个视图 设计每个视图的显示形式它从模型中获取数据将它们显示在屏幕上。 3.3 设计和实现每个控制器 对于每个视图指定对用户操作的响应时间和行为。在模型状态的影响下控制器使用特定的方法接受和解释这些事件。控制器的初始化建立起与模型和视图的联系并且启动事件处理机制。事件处理机制的具体实现方法依赖于界面的工作平台。 3.4 使用可安装和卸载的控制器 控制器的可安装性和可卸载性带来了更高的自由度并且帮助形成高度灵活性的应用。控制器与视图的分离支持了视图与不同控制器结合的灵活 性以实现不同的操作模式例如对普通用户、专业用户、或不使用控制器建立的只读视图。这种分离还为在应用中集成新的I/O设备提供了途径。 4 MVC的变化 把模型、视图、控制器实行分离使设计和使用有了很大灵活性。但是在现实中视图和控制器的功能通常是紧密地联系在一起的。控制视图工作的 输入事件通常都是与视图的构成相关的。在现实界面设计环境中界面操作事件及其处理都是与界面形式设计紧密关联的。在这种情况下把视图和控制器分离开 就给分析和设计带了了不方便并且运行的效率低。 因此可以把视图和控制器结合起来加以设计和实现。在上面的实现说明中只要把视图和控制器的类合并生成新的视图类即可。这样仍然保持着与模型的分离因此相同的模型仍然可以使用多个视图。这些视图本身已经具备了事件处理能力仍然可以通过模型对其功能进行控制。 5 MVC的优点及不足之处 5.1 MVC的优点 MVC的优点表现在以下几个方面 1 可以为一个模型在运行时同时建立和使用多个视图。变化-传播机制可以确保所有相关的视图及时得到模型数据变化从而使所有关联的视图和控制器做到行为同步。 2 视图与控制器的可接插性允许更换视图和控制器对象而且可以根据需求动态的打开或关闭、甚至在运行期间进行对象替换。 3 模型的可移植性。因为模型是独立于视图的所以可以把一个模型独立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进行新的修改。 4 潜在的框架结构。可以基于此模型建立应用程序框架不仅仅是用在设计界面的设计中。 5.2 MVC的不足之处 MVC的不足表现在以下几个方面 1 增加了系统结构和实现的复杂性。对于简单的界面严格遵循MVC使模型、视图与控制器分离会增加结构的复杂性并可能产生过多的更新操作降低运行效率。 2 视图与控制器间的过于紧密的连接。视图与控制器是相互分离但确实联系紧密的部件视图没有控制器的存在其应用是很有限的反之亦然这样就妨碍了他们的独立重用。 3视图对模型数据的低效率访问。依据模型操作接口的不同视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问也将损害操作性能。 4 目前一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的从而造成使用MVC的困难。 6 其他类似的模式 类似的结构模式还有PACPresentation-Abstraction-Control、Forward-Receiver、Publisher-Subscriber、各类可视化用户界面控件等。 其中表示-抽象-控制结构模式PAC也是从数据模型及其可是化关系的处理上提出的。其中表示与视图对应抽象与模型对应控制与控制对应。从逻辑本质上两者没有太大区别。但是MVC和PAC还是存在着不同的地方。 1 MVC的控制更侧重于在视图上的用户的I/O处理而PAC的控制主要指从抽象到表示的传递和协调作用。 2 此外PAC把系统分割为协作但松散耦合的智能体而MVC是专门处理交互界面的各个部件之间的关联更密切一些。 3 另外从体系结构上看PAC是属于系统级别的因为它解决的问题更倾向于系统及部件之间的协作和关联关系。 7 小结 与软件所处理问题的内在模型相比较用户界面是需要经常发生变化的采用MVC设计模式可以在满足对界面要求的同时使软件的计算模型独立于 界面的构成。本文首先介绍了MVC的三个组成构件模型构件、视图构件和控制构件以及实现基于MVC的应用需要完成的工作接着对MVC的优点及不 足之处进行了分析最后介绍了几种其他类似的结构模式并对MVC和PAC进行了比较。 8 参考书目 1 万建成、卢雷 编著《软件体系结构的原理、组成与应用》科学出版社2002 2 齐治昌、谭庆平、宁洪 编著 《软件工程》 北京高等教育出版社 1997 3 美Roger S.Pressman 著黄柏素、梅宏译 《软件工程──实践者的研究方法第四版》北京机械工业出版社 1999 转载于:https://www.cnblogs.com/QuitGame/archive/2005/02/28/110072.html
