MVC Pattern Application and Research in Creating Charts Component
　　DING Min-dou
　　(Nanjing Institute of Railway Technology, Nanjing 210015, China)
　　Abstract: MVC mode or structure because of its high cohesion and low coupling characteristics, in an object-oriented design in a wide range of applications. In this paper, the chart components as an example, this paper discusses the object-oriented design process, how to properly reasonably application MVC pattern, will view, model and the controller to each other, stripped of object-oriented design goal.
　　Key words: MVC mode; high cohesion; low coupling; object-oriented design goal; chart components
　　仅仅能够使用面向对象语言进行系统开发，并不能表示掌握了面向对象思想，从而不能保证开发出的系统能够应对各种“需求的变更”。按照软件工程的理论，面向对象设计目标的核心就是使设计的系统具有可扩展性、可维护性和可复用性。为达此目标，在系统设计时必须遵循面向对象设计原则，使组成系统的各个组件内部实现高内聚，组件之间实现弱耦合。MVC结构就是具有高内聚、弱耦合的一种设计模式。本文以图表组件为例，对MVC模式的应用进行一些探索与研究。
　　1 面向对象设计的应用
　　1.1 面向对象设计原则
　　目前常用的面向对象设计原则主要包括：
　　1）单一职责原则。
　　就一个类而言，应该仅有一个引起它变化的原因。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。
　　2）开放－封闭原则。
　　软件组件（包括类、模块和函数等）必须能够扩展其功能而不必修改其代码。即，对于扩展是开放的，对于更改是封闭的。该原则是软件工程设计方法的重要原则之一，同时也是面向对象设计原则的基石。
　　3）Liskov替换原则（里氏替换原则）
　　该原则就是子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。
　　4）依赖倒置原则。
　　高层模块不应该依赖于低层模块。二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。
　　5）接口隔离原则。
　　采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。不遵循该原则的软件组件的可用性和移植性将大打折扣。
　　1.2 MVC模式
　　MVC（是Model—View—Controller的简称，即模型—视图—控制器）模式是一种目前被广泛应用的软件组件结构或模式。
　　在该模式中，一个组件或模块被分成三个层次——模型层、视图层和控制层，实现了将数据或输入处理、数据显示和流程控制相互剥离，各自承担其职责，完成不同的任务。MVC模式的结构如图1所示。
　　1）视图。
　　视图(View)提供了用户交互的界面，一个应用可能有很多不同的视图。在MVC模式中，对于视图的处理仅限于视图上数据的采集和显示，以及用户的请求，而不包括任何实际的业务流程处理，业务流程的处理由模型(Model)实现。视图可以向模型查询业务状态，但不能改变模型中的数据。以及将用户界面的输入数据和请求传递给控制器。此外，视图还能接受模型发出的数据更新事件，从而对用户界面进行同步更新。
　　2）模型。
　　模型(Model)是应用程序的主体部分，具体实现业务流程或业务状态的处理以及业务规则的定制。业务流程的处理过程对其它层而言是黑箱操作的，模型接受视图请求的数据，并返回最终的处理结果。
　　3）控制器。
　　控制器（Control）用于接收用户的输入并调用模型和视图完成用户请求。控制器的主要工作就是协调请求处理、将用户输入转换为模型的更新和视图的选择。控制器本质上就是一个任务分发器，负责选择相应的模型和视图，然后调用所选择的模型和视图以完成用户请求的处理。控制器并不进行任何的数据处理。一个应用可能有多个控制器，每个控制器只负责应用的某个特定领域的处理。
　　1.3 MVC模式的处理过程
　　用户通过系统提供的视图界面发出请求，视图把该请求转发给控制器，控制器调用相应的模型处理该用户请求，模型根据视图的要求进行相应的业务逻辑处理，并将处理结果返回给控制器，控制器选择并调用相应的视图完成处理结果的显示。具体处理顺序图如图2所示。
　　在现实开发中，由于实际需要，开发设计人员通常会对标准的 mvc 模式进行一些修改。屏弃其中的某些特性，而加入新的特性。其中最常见的变化形式如图3所示。
　　可以看到，控制器并没有完全分离视图与模型。即它不再负责根据模型修改视图，这一过程由模型与视图直接交互。这样做虽然加大了视图与模型之间的耦合，但是减轻了控制器的负担。
　　1.4 问题的引入
　　图表通常有柱状图、折线图、饼图等种类，由于以图表形式显示数据具有直观性，所以图表在日常生活或工作中得到普遍的使用。而在JDK API中并没有提供图表组件，因此在系统开发过程中，若需要以图表形式显示数据，将会给开发人员带来很大的不便。因此，本文尝试设计基于MVC结构的、具有灵活性、可复用性和可扩展性的图表组件。
　　1.5 解决方案
　　1.5.1 设计思想
　　为了使图表组件达到面向对象的设计目标，即具有可扩展性、灵活性和可维护性，在设计过程中采取如下设计思想：
　　1）使用XML文件保存图表属性动态地装载图表信息。
　　充分应用XML的层次结构和Java的反射机制。使用XML文件保存图表的属性信息，包括图表类型及其他数据。在系统启动时，应用Java反射机制，动态地装载图表信息，从而为实现功能可扩展打下基础。
　　2）基于MVC模式来设计图表组件。
　　充分应用MVC这种高内聚、低耦合的设计模式，实现数据处理、数据显示或输入、流程控制的剥离。视图接收用户的输入，包括图表类型等图表属性数据，通过事件触发控制器来通知模型处理这些输入的数据，并使视图及时显示这些处理过的数据。利用面向抽象或接口的编程实现组件的灵活性。由于采用了弱耦合的设计，更改了某个图表业务逻辑后，不会对组件的其他部分产生影响，便于组件的维护。 (责任编辑：南粤论文中心)转贴于南粤论文中心: http://www.nylw.net(南粤论文中心__代写代发论文_毕业论文带写_广州职称论文代发_广州论文网）