对mvc的理解

谈谈你对MVC的理解

MVC是Model—View—Controler的简称。即模型—视图—控制器。MVC是一种设计模式，它强制性的把应用程序的输入、处理和输出分开。

MVC中的模型、视图、控制器它们分别担负着不同的任务。

视图: 视图是用户看到并与之交互的界面。视图向用户显示相关的数据，并接受用户的输入。视图不进行任何业务逻辑处理。

模型: 模型表示业务数据和业务处理。相当于JavaBean。一个模型能为多个视图提供数据。这提高了应用程序的重用性

控制器: 当用户单击Web页面中的提交按钮时,控制器接受请求并调用相应的模型去处理请求。

然后根据处理的结果调用相应的视图来显示处理的结果。

MVC的处理过程：首先控制器接受用户的请求，调用相应的模型来进行业务处理，并返回数据给控制器。控制器调用相应的视图来显示处理的结果。并通过视图呈现给用户。

2.项目中为什么使用SSH

(1). 使用Struts是因为struts是基于MVC模式的,很好的将应用程序进行了分层，使开发者更关注于业务逻辑的实现；第二，struts有着丰富的taglib,如能灵活运用，则能大大提高开发效率。

(2). 使用Hibernate：因为hibernate为Java应用提供了一个易用的、高效率的对象关系映射框架。hibernate是个轻量级的持久性框架，功能丰富。

(3). 使用Spring：因为spring基于IoC(Inversion of Control，反向控制)和AOP构架多层j2ee系统的框架，但它不强迫你必须在每一层中必须使用Spring，因为它模块化的很好，允许你根据自己的需要选择使用它的某一个模块；采用IoC使得可以很容易的实现bean的装配，提供了简洁的AOP并据此实现事务管理(Transcation Managment),等等 

3. JAVA三大框架的各自作用 

 hibernate是底层基于jdbc的orm(对象关系映射)持久化框架，即：表与类的映射，字段与属性的映射，记录与对象的映射 数据库模型 也就是Model;

 struts提供的丰富标签是用于显示层View;同时struts也充当了实现Control的功能(不管是Struts1，还是Struts2)，接收参数，视图分发。

 Spring是用于降低层与层间耦合度的，就是所有的类都可以由spring统一创建，用时只需注入即可(IOC)

 从功能上来说，hibernate为M，struts2 为V，也可以为C，spring可以为C。

 但大多数项目中，hibernate为M，struts2 为V+C，spring用来帮助管理类以及实现一些业务无关功能，如日志记录等，大多数都是用struts来做C的。

比如说写一个 Todo List, 按照前端的 MVC 这样写:

• Model: 一个 JSON 数组, 对应存在数据库的内容, 就是文本啊, 完成状态
• View: HTML 模版, 或者 DOM 模版, 也就是界面
• Controller: 用户在界面上操作, 进而对 Model 进行更改的操作

一般有这样的关系(不是很准确, 而且各种 MVC 实现也不完全一致):

• 整个程序围绕 Model 的改变来更新
• View 根据 Model 渲染, 随着 Model 更新而更新
• Controller 接收 View 当中的事件触发, 对 Model 进行修改

整体上是一个循环~ 从 Model 开始, 中间加上用户操作, 又作用回到 Model
这是写图形的一个思路, 就是把数据跟界面区分开来, 简化程序.
或者说, 抽象出表示一个界面最少的数据作为 Model, 最少的操作作为 Controller.
而 View, 跟着 Model 变, 甚至根据用户需要随意进行改变.

MVC就不一样，数据处理和展示是分开的。
业务不复杂的时候基本V和C就能搞定。
C哥把数据处理好，打包交给V。郑重的给V说：“V哥，数据都在这里了，您拿去显示吧！”
V说：“好的C哥！” 然后就把数据展现在前端。V哥也有类似foreach等的语法，用来展示C哥给的数据。

有时候业务复杂了，C哥一个人处理数据有点累，C哥就喊M哥来帮忙。M哥帮C哥做一些重复性工作，处理好后给C哥。再由C哥转交给V哥。

最形象最简单的莫过于把MVC比作小时候玩的插卡式的游戏机：
M：就是游戏卡，保存数据，负责业务逻辑等
V：就是电视机，负责呈现游戏的画面
C：就是游戏控制手柄，负责前两者之间的交互

1.

如何设计一个程序的结构，这是一门专门的学问，叫做"架构模式"（architectural pattern），属于编程的方法论。

MVC模式就是架构模式的一种，它对我的启发特别大。我觉得它不仅适用于开发软件，也适用于其他广泛的设计和组织工作。

下面是我对MVC模式的一些个人理解，不一定正确，主要用来整理思路。

2.

MVC是三个单词的首字母缩写，它们是Model（模型）、View（视图）和Controller（控制）。

这个模式认为，程序不论简单或复杂，从结构上看，都可以分成三层。

1）最上面的一层，是直接面向最终用户的"视图层"（View）。它是提供给用户的操作界面，是程序的外壳。

2）最底下的一层，是核心的"数据层"（Model），也就是程序需要操作的数据或信息。

3）中间的一层，就是"控制层"（Controller），它负责根据用户从"视图层"输入的指令，选取"数据层"中的数据，然后对其进行相应的操作，产生最终结果。

这三层是紧密联系在一起的，但又是互相独立的，每一层内部的变化不影响其他层。每一层都对外提供接口（Interface），供上面一层调用。这样一来，软件就可以实现模块化，修改外观或者变更数据都不用修改其他层，大大方便了维护和升级。

3.

我用Windows的计算器小程序为例，解释一下MVC模式，虽然它不一定使用这个模式编写。

在这个计算器程序中，外部的那些按钮和最上面的显示条，就是"视图层"，那些需要运算的数字就是"数据层"，执行加减乘除的那些内部运算步骤就是"控制层"。每一层执行不同的功能，整个程序的结构非常清楚。

如果我们扩大一点想象，就会发现，很多程序本质上都是这种模式：对外提供一组触发器（本例中是按钮），然后执行一些内部操作，最后返回结果。因此，MVC模式的应用是非常广泛的。

4、

在我看来，不仅编写程序可以用MVC模式，家用电器也可以用。

以家用微波炉为例，可以将它也理解成三层结构。最简单的情况下，微波炉的操作用两个转盘实现，一个控制温度，另一个控制时间。这两个转盘就是"视图层"（view），而其内部的微波产生装置则是"数据层"（Model），这里的"数据"需要理解成"核心功能"。至于将用户通过转盘输入的信息，转换成对微波产生器的操作，则用"控制层"来实现。

如果每一层都是独立的，那么微波炉外部更换一个新潮的外壳，或者内部更换更大功率的微波产生器，完全可以在不更改其他层的情况下实现。这就是MVC模式的优势。

5.

再进一步，如果将MVC模式解释成"外观"、"机制"和"功能/数据"这三层结构，那么很多人类组织也可以通过MVC模式架构。

比如一家商场，完全可以分成三部分。一部分是仓库，负责提供商品，这是"功能层"（或者"数据层"）；另一部分是零售铺面，负责销售商品，这是它的"外观层"；两者之间就是"机制层"，包括柜台和仓库之间一切互动的机制。

这样区分以后，这个商场的结构就变得非常清楚，可以针对不同的层进行优化，提高效率。

6.

公司、政党、政府、医院、学校等等，这些组织不管是盈利性还是非盈利性的，都可以从MVC模式的角度，进行架构，由一个个执行特定功能、可重复使用的模块组成。