B/S构架MVC系统设计模式
一. 目的
提高代码重用、增加开发速度和减少维护修改量已经成为现软件开发模式中日益提升的需求。框架、模型和接口也就随此孕育而生。
MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。使用MVC设计模式能够使得开发人员可以把精力集中在如何解决实际业务问题上。
为什么要使用 MVC
大部分Web应用程序都是用像JSP，ASP，PHP，或者CFML这样的过程化语言来创建的。它们将像数据库查询语句这样的数据层代码和像HTML这样的表示层代码混在一起。经验比较丰富的开发者会将数据从表示层分离开来，但这通常不是很容易做到的，它需要精心的计划和不断的尝试。MVC从根本上强制性的将它们分开。尽管构造MVC应用程序需要一些额外的工作，但是它给我们带来的好处是无庸质疑的。
首先，最重要的一点是多个视图能共享一个模型，正如我所提及的，现在需要用越来越多的方式来访问你的应用程序。对此，其中一个解决之道是使用MVC，无论你的用户想要Flash界面或是 WAP 界面；用一个模型就能处理它们。由于你已经将数据和业务规则从表示层分开，所以你可以最大化的重用你的代码了。
由于模型返回的数据没有进行格式化，所以同样的构件能被不同界面使用。例如，很多数据可能用HTML来表示，但是它们也有可能要用Macromedia Flash和WAP来表示。模型也有状态管理和数据持久性处理的功能，例如，基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序所重用。
因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变你的应用程序的数据层和业务规则。如果你想把你的数据库从MySQL移植到Oracle，或者改变你的基于RDBMS数据源到LDAP，只需改变你的模型即可。一旦你正确的实现了模型，不管你的数据来自数据库或是LDAP服务器，视图将会正确的显示它们。由于运用MVC的应用程序的三个部件是相互对立，改变其中一个不会影响其它两个，所以依据这种设计思想你能构造良好的松偶合的构件。
对我们来说，控制器的也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。
二. B/S 构架MVC设计模式图
无法显示，使用文字简单描述：
信息层:关系数据库
数据持久化层: DAO
模型层:业务对象(Business Object)、业务逻辑、业务代理接口、控制器
视图层：视图
客户层：IE
三. 设计模式描述
根据上图B/S三层构架设计模式，我们把数据库信息层单独放置为底层，数据持久化层、模型层和控制器层视为中间层，视图层为客户端显示操作界面，处于最上层，也是程序直接接受操作层。
3.1. 数据的持久化
持久化意味着通过手工或者其他方式输入到应用中的数据能够在应用结束运行后依然存在。这就需要数据被持久化到数据库或磁盘文件。
面向对象的开发方法是当今的主流，但是同时不得不使用关系型数据库，在企业级开发的环境中，对象——系的映射（Object - Relation Mapping， 简称ORM）也就成为持久化操作的一个重要环节。围绕ORM和持久化数据的访问，在软件领域中发展起来了一种数据访问对象（Data Access Object， 简称DAO）设计模式。
对于java 应用，可以直接通过JDBC 编程来访问数据库，在企业级应用开发中，可以通过JDBC编程来开发自己的DAO API，把数据访问操作封装起来，供业务层统一调用。
3.2. 业务对象
业务对象（Business Object， 简称 BO），即是对真实世界的实体的软件抽象。它可以代表业务领域中的人、地点、事物或概念。业务对象包括状态和行为。
如果一个类可以作为业务对象，那么它应该具有以下特征：
a、包含状态和行为
b、代表业务领域的人、地点、事物或概念
c、可以重用
业务对象可分为三种类型：
a、实体业务对象
b、过程业务对象
c、事件业务对象
通过不同类型的业务对象相互组合调用，构成业务逻辑层，是模型层核心部分。
3.3. 业务代理接口
业务代理接口直接访问、组合业务对象和持久化框架，处理实际的业务逻辑，使用业务代理接口，可以让控制器使用这些代理接口，而不必直接和持久化框架交互。这种做法有助于消弱上层web应用和持久化框架之间的关系，提高持久化框架和模型的相对独立性。
此外，还需要采用DAO模式来消弱应用的业务逻辑和数据库访问逻辑的关系，当使用持久化框架的时候，DAO模式可以把业务对象和持久化框架分开，当持久化机制发生改变时，这种改变不会对业务对象产生影响。
3.4. 控制器
控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后用确定用哪个视图来显示模型处理返回的数据。控制器负责统一控制程序流转和计算，相当于CPU的功能。当客户端发送操作请求后，由控制器接收请求并根据请求调用业务代理接口来完成请求，最后返回请求结果。
Struts 框架是一种位于MVC模式开发中扮演控制器角色的web框架应用。它位于程序的控制层，不负责具体实现业务逻辑，只负责创建和调用模型接口来实现业务逻辑的请求。Struts 框架可以做到统一控制流程，在统一控制中又细分出单个事件的请求控制。
把控制层和视图、模型层分开的好处是，无论是业务逻辑和视图中的哪个组件发生改变，他们都只需要改变本身的那部分，而不需要设计其他的层次。
3.5. 视图
视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色。
如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。
Struts 框架也提供了视图组件，基于Struts 的视图 API，可以使程序开发速度提高，机构严禁，最重要的是可以把控制器和视图完全分开，以消弱视图中混合控制的机制，达到真正的模块独立。
3.6. 总结
现在我们总结ＭVC的处理过程，首先控制器接收用户的请求，并决定应该调用哪个模型来进行处理，然后模型用业务逻辑来处理用户的请求并返回数据，最后控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。
四. 层次间关系
从视图层到持久化层，他们只能调用在它下一层的接口，不允许跳跃式调用，从而使各层次间相对独立，以达到增加重用、减少维护、修改工作量和模块化的目标。
五. 软件项目开发流程图
此处无法显示
六. 应用实现技术
信息层：Oracle
持久化层：自定义DAO框架、java EJB 实体Bean
业务对象：自定义class或第三方API，java EJB Session Bean
业务代理接口： interface
控制器： Struts Action
视图： Struts taglib， 自定义taglib， JavaScript
七. 团队
需求分析师：负责业务需求分析
系统构架师：负责系统构架每个模块
系统设计师：负责设计模块的业务对象和业务逻辑框架
软件工程师：负责实现业务逻辑、控制器和视图控制
界面设计时：负责界面设计
八. 开发模式
无论是软件整体构架还是分模块构架，都必须有个明确的团队分工合作，以下简单说明模块开发中的流程
需求分析师 —— 进行业务逻辑分析，完成后交给系统构架师。
系统构架师 —— 在得到需求分析后，系统构架师根据需求首先进行设计概念模型，在此步工作中，需要把业务对象细致地抽象出来，并设计出整体模块的框架，完成后交给系统设计师。
系统设计师 —— 在获取模块设计框架后，根据设计把概念模型抽象成业务对象模型，并且需要根据需求设计出整个模块的业务逻辑框架和接口。完成后分别把逻辑框架和接口交给负责完成业务逻辑的软件工程师和负责控制器视图设计的软件工程师。
各个软件工程师在得到设计文档后可以开始同步完成代码编辑工作和视图设计编程工作。
软件工程师完后工作后把程序发布，交给测试工程师，测试工程师根据视图完成测试用例编写，并开始测试，完成后需要编写测试报告。如果有BUG则退回软件工程师，如果有业务逻辑改变，则有软件工程师退回给系统设计师重新设计或改写业务逻辑。无问题后由软件工程师完成自己负责的模块用户手册。
至此，模块开发完毕，交付。
九. 参考文献
本文参考以下文档
a、CSDN中发表的技术文章
b、孙卫琴的《精通Struts：基于MVC的Java Web设计与开发 》
提高代码重用、增加开发速度和减少维护修改量已经成为现软件开发模式中日益提升的需求。框架、模型和接口也就随此孕育而生。
MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。使用MVC设计模式能够使得开发人员可以把精力集中在如何解决实际业务问题上。
为什么要使用 MVC
大部分Web应用程序都是用像JSP，ASP，PHP，或者CFML这样的过程化语言来创建的。它们将像数据库查询语句这样的数据层代码和像HTML这样的表示层代码混在一起。经验比较丰富的开发者会将数据从表示层分离开来，但这通常不是很容易做到的，它需要精心的计划和不断的尝试。MVC从根本上强制性的将它们分开。尽管构造MVC应用程序需要一些额外的工作，但是它给我们带来的好处是无庸质疑的。
首先，最重要的一点是多个视图能共享一个模型，正如我所提及的，现在需要用越来越多的方式来访问你的应用程序。对此，其中一个解决之道是使用MVC，无论你的用户想要Flash界面或是 WAP 界面；用一个模型就能处理它们。由于你已经将数据和业务规则从表示层分开，所以你可以最大化的重用你的代码了。
由于模型返回的数据没有进行格式化，所以同样的构件能被不同界面使用。例如，很多数据可能用HTML来表示，但是它们也有可能要用Macromedia Flash和WAP来表示。模型也有状态管理和数据持久性处理的功能，例如，基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序所重用。
因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变你的应用程序的数据层和业务规则。如果你想把你的数据库从MySQL移植到Oracle，或者改变你的基于RDBMS数据源到LDAP，只需改变你的模型即可。一旦你正确的实现了模型，不管你的数据来自数据库或是LDAP服务器，视图将会正确的显示它们。由于运用MVC的应用程序的三个部件是相互对立，改变其中一个不会影响其它两个，所以依据这种设计思想你能构造良好的松偶合的构件。
对我们来说，控制器的也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。
二. B/S 构架MVC设计模式图
无法显示，使用文字简单描述：
信息层:关系数据库
数据持久化层: DAO
模型层:业务对象(Business Object)、业务逻辑、业务代理接口、控制器
视图层：视图
客户层：IE
三. 设计模式描述
根据上图B/S三层构架设计模式，我们把数据库信息层单独放置为底层，数据持久化层、模型层和控制器层视为中间层，视图层为客户端显示操作界面，处于最上层，也是程序直接接受操作层。
3.1. 数据的持久化
持久化意味着通过手工或者其他方式输入到应用中的数据能够在应用结束运行后依然存在。这就需要数据被持久化到数据库或磁盘文件。
面向对象的开发方法是当今的主流，但是同时不得不使用关系型数据库，在企业级开发的环境中，对象——系的映射（Object - Relation Mapping， 简称ORM）也就成为持久化操作的一个重要环节。围绕ORM和持久化数据的访问，在软件领域中发展起来了一种数据访问对象（Data Access Object， 简称DAO）设计模式。
对于java 应用，可以直接通过JDBC 编程来访问数据库，在企业级应用开发中，可以通过JDBC编程来开发自己的DAO API，把数据访问操作封装起来，供业务层统一调用。
3.2. 业务对象
业务对象（Business Object， 简称 BO），即是对真实世界的实体的软件抽象。它可以代表业务领域中的人、地点、事物或概念。业务对象包括状态和行为。
如果一个类可以作为业务对象，那么它应该具有以下特征：
a、包含状态和行为
b、代表业务领域的人、地点、事物或概念
c、可以重用
业务对象可分为三种类型：
a、实体业务对象
b、过程业务对象
c、事件业务对象
通过不同类型的业务对象相互组合调用，构成业务逻辑层，是模型层核心部分。
3.3. 业务代理接口
业务代理接口直接访问、组合业务对象和持久化框架，处理实际的业务逻辑，使用业务代理接口，可以让控制器使用这些代理接口，而不必直接和持久化框架交互。这种做法有助于消弱上层web应用和持久化框架之间的关系，提高持久化框架和模型的相对独立性。
此外，还需要采用DAO模式来消弱应用的业务逻辑和数据库访问逻辑的关系，当使用持久化框架的时候，DAO模式可以把业务对象和持久化框架分开，当持久化机制发生改变时，这种改变不会对业务对象产生影响。
3.4. 控制器
控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后用确定用哪个视图来显示模型处理返回的数据。控制器负责统一控制程序流转和计算，相当于CPU的功能。当客户端发送操作请求后，由控制器接收请求并根据请求调用业务代理接口来完成请求，最后返回请求结果。
Struts 框架是一种位于MVC模式开发中扮演控制器角色的web框架应用。它位于程序的控制层，不负责具体实现业务逻辑，只负责创建和调用模型接口来实现业务逻辑的请求。Struts 框架可以做到统一控制流程，在统一控制中又细分出单个事件的请求控制。
把控制层和视图、模型层分开的好处是，无论是业务逻辑和视图中的哪个组件发生改变，他们都只需要改变本身的那部分，而不需要设计其他的层次。
3.5. 视图
视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色。
如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。
Struts 框架也提供了视图组件，基于Struts 的视图 API，可以使程序开发速度提高，机构严禁，最重要的是可以把控制器和视图完全分开，以消弱视图中混合控制的机制，达到真正的模块独立。
3.6. 总结
现在我们总结ＭVC的处理过程，首先控制器接收用户的请求，并决定应该调用哪个模型来进行处理，然后模型用业务逻辑来处理用户的请求并返回数据，最后控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。
四. 层次间关系
从视图层到持久化层，他们只能调用在它下一层的接口，不允许跳跃式调用，从而使各层次间相对独立，以达到增加重用、减少维护、修改工作量和模块化的目标。
五. 软件项目开发流程图
此处无法显示
六. 应用实现技术
信息层：Oracle
持久化层：自定义DAO框架、java EJB 实体Bean
业务对象：自定义class或第三方API，java EJB Session Bean
业务代理接口： interface
控制器： Struts Action
视图： Struts taglib， 自定义taglib， JavaScript
七. 团队
需求分析师：负责业务需求分析
系统构架师：负责系统构架每个模块
系统设计师：负责设计模块的业务对象和业务逻辑框架
软件工程师：负责实现业务逻辑、控制器和视图控制
界面设计时：负责界面设计
八. 开发模式
无论是软件整体构架还是分模块构架，都必须有个明确的团队分工合作，以下简单说明模块开发中的流程
需求分析师 —— 进行业务逻辑分析，完成后交给系统构架师。
系统构架师 —— 在得到需求分析后，系统构架师根据需求首先进行设计概念模型，在此步工作中，需要把业务对象细致地抽象出来，并设计出整体模块的框架，完成后交给系统设计师。
系统设计师 —— 在获取模块设计框架后，根据设计把概念模型抽象成业务对象模型，并且需要根据需求设计出整个模块的业务逻辑框架和接口。完成后分别把逻辑框架和接口交给负责完成业务逻辑的软件工程师和负责控制器视图设计的软件工程师。
各个软件工程师在得到设计文档后可以开始同步完成代码编辑工作和视图设计编程工作。
软件工程师完后工作后把程序发布，交给测试工程师，测试工程师根据视图完成测试用例编写，并开始测试，完成后需要编写测试报告。如果有BUG则退回软件工程师，如果有业务逻辑改变，则有软件工程师退回给系统设计师重新设计或改写业务逻辑。无问题后由软件工程师完成自己负责的模块用户手册。
至此，模块开发完毕，交付。
九. 参考文献
本文参考以下文档
a、CSDN中发表的技术文章
b、孙卫琴的《精通Struts：基于MVC的Java Web设计与开发 》
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
