MVC设计模式

MVC模式（Model-View-Controller）是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）
它是用一种业务逻辑、数据与界面显示分离的方法来组织代码，将众多的业务逻辑聚集到一个部件里面，在需要改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑，达到减少编码的时间，提高代码复用性。

控制器（Controller）：Servlet，控制器主要处理用户的请求。
指从现实世界中抽象出来的对象模型，是应用逻辑的反应；它封装了数据和对数据的操作，是实际进行数据处理的地方（模型层与数据库才有交互）

视图（View）：HTML, JSP, 前端框架。是应用和用户之间的接口，它负责将应用显示给用户 和 显示模型的状态。

模型（Model）：逻辑业务程序（后台的功能程序）, Service, Dao, JavaBean。
控制器负责视图和模型之间的交互，控制对用户输入的响应、响应方式和流程；它主要负责两方面的动作，一是把用户的请求分发到相应的模型，二是吧模型的改变及时地反映到视图上。

V即View视图是指用户看到并与之交互的界面。比如由html元素组成的网页界面，或者软件的客户端界面。MVC的好处之一在于它能为应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，它只是作为一种输出数据并允许用户操纵的方式。

C即controller控制器是指控制器接受用户的输入并调用模型和视图去完成用户的需求，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。

用户首先在界面中进行人机交互，然后请求发送到控制器，控制器根据请求类型和请求的指令发送到相应的模型，模型可以与数据库进行交互，进行增删改查操作，完成之后，根据业务的逻辑选择相应的视图进行显示，此时用户获得此次交互的反馈信息，用户可以进行下一步交互，如此循环。

需要注意的是：MVC三层结构与软件的三层结构是有区别的。MVC是一种设计模式，三层结构是软件结构，用MVC这种设计模式可以实现三层软件结构。在完整三层软件结构中 表现层包括了MVC中的表现层和控制层。而MVC中的模型层其实包括了三层软件结构的业务逻辑层、数据访问层、业务实体类（model）和共用类。软件三层结构的UI（Web）包含了MVC中的视图层（V）和控制层（C）。

MVC的目的

它将这些对象、显示、控制分离以提高软件的的灵活性和复用性，MVC结构可以使程序具有对象化的特征，也更容易维护。

MVC举例

jsp+servlet+javabean模式

JavaBean作为模型，既可以作为数据模型来封装业务数据，又可以作为业务逻辑模型来包含应用的业务操作。其中，数据模型用来存储或传递业务数据，而业务逻辑模型接收到控制器传过来的模型更新请求后，执行特定的业务逻辑处理，然后返回相应的执行结果。

JSP作为视图层，负责提供页面为用户展示数据，提供相应的表单（Form）来用于用户的请求，并在适当的时候（点击按钮）向控制器发出请求来请求模型进行更新。

Serlvet作为控制器，用来接收用户提交的请求，然后获取请求中的数据，将之转换为业务模型需要的数据模型，然后调用业务模型相应的业务方法进行更新，同时根据业务执行结果来选择要返回的视图。

MVC设计模式相对于模式1（虚线表示模式1，不是MVC，即JSP+JavaBean），把模式1 的表现层中的页面与表现逻辑（流程控制）分开。
视图层只负责页面的显示，而数据的获取、调用业务逻辑和页面的选择均由控制层完成。
在MVC模式中，视图层用JSP、HTML、CSS和JavaScript技术来实现；

MVC的优点

1.耦合性低

视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。

2.重用性高

MVC模式允许使用各种不同样式的视图来访问同一个服务器端的代码，因为多个视图能共享一个模型，它包括任何WEB（HTTP）浏览器或者无线浏览器（wap），比如，用户可以通过电脑也可通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面使用。

3.部署快，生命周期成本低

MVC使开发和维护用户接口的技术含量降低。使用MVC模式使开发时间得到相当大的缩减，它使程序员（Java开发人员）集中精力于业务逻辑，界面程序员（HTML和JSP开发人员）集中精力于表现形式上。

4.可维护性高

分离视图层和业务逻辑层也使得WEB应用更易于维护和修改。

MVC的缺点

1.完全理解MVC比较复杂

由于MVC模式提出的时间不长，加上同学们的实践经验不足，所以完全理解并掌握MVC不是一个很容易的过程。

2.调试困难

因为模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难，每个构件在使用之前都需要经过彻底的测试。

3.不适合小型，中等规模的应用程序

在一个中小型的应用程序中，强制性的使用MVC进行开发，往往会花费大量时间，并且不能体现MVC的优势，同时会使开发变得繁琐。

4.增加系统结构和实现的复杂性

对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。

5.视图与控制器间的过于紧密的连接并且降低了视图对模型数据的访问

视图与控制器是相互分离，但却是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。

依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。

Modle 发展史

JSP Model1第一代
所有的业务逻辑交个jsp单独处理完成，一个web项目只存在DB层和JSP层，所有的东西都耦合在一起，对后期的维护和扩展极为不利。

JSP Model1第二代

JSP Model1第二代有所改进，把业务逻辑的内容放到了JavaBean中，而JSP页面负责显示以及请求调度的工作。虽然第二代比第一代好了些，但JSP还是把view和control的业务耦合在一起。

JSP Model2
JSP Model2 就是现在大力推广的和使用的mvc，将一个项目划分为三个模块，各司其事互不干扰，既解决了jsp所形成的耦合性，又增加了逻辑性、业务性以及复用性和维护性。

项目分层

DAO —— Data Access Object数据访问对象（接口）
DAOImpl —— DAO的实现类
entity ——数据对象的实体（有些地方叫model层）
Service（不是Server）——就是中间层、业务逻辑层（接口）
ServiceImpl —Service的实现类
Util —— 自定义工具类 Servlet——JAVA WEB小应用（有时叫Controller层）

1、Utils：主要用于存放连接工具如java数据库连接工具,在这里提供连接和关闭数据库的接口。
2、Dao层: 上面Util包中已经提供连接数据库接口，在本层中可直接调用，然后创建增删改查语句。
3、Service层：最重要的一层，对servlet层传入的数据，调用Dao层的方法操作和整合。
4、Servlet层：对Jsp中传入的数据，封装调用service操作。
5、test层：用单元测试的方式，没有问题再进行接下来的操作。
6、Bean层里是建立的模型层
一般情况下，Dao层、service层还要分为两层，一层是接口，另外一层做实现类。

1.JAVA中Servlet层、Service层 、modle层 、 Dao层的功能区分？

Servlet层用于接收请求并且调用对应service层处理请求，是Java各层中最接近浏览器的一层。Service层主要编写具体业务逻辑，每个Service一般包含一组相关的业务逻辑

modle/entity层（统称模型层）对应的数据库表的实体类，一般每个模型层类对应一个数据库“表”，一般是用于ORM对象关系映射，一方面方便从数据库取数据时保存为类，一方面也方便写入数据库，简而言之就是为了方便操作数据库

Dao层一般用于对数据库的具体操作，包括各种具体的增删改查语句和数据库数据和Java模型的映射。Util层主要用于存在项目各层都有可能出现、不好划分到某层中、出现频率较高的功能（类），比如连接数据库、获取系统参数、导出Excel表等等

2.为什么将Service（Dao）层设为接口层，单独拿出一个ServiceImpl（DaoImpl）作为实现层？

方便项目管理，增加代码的复用性。
当项目很大、代码很多时，可能存在多种业务逻辑类似但具体业务有所区别的需求，此时让它们都集成同一个接口层方便处理。

3.为什么要用service层封装？

一般某一个程序的有些业务流程需要连接数据库，有些不需要与数据库打交道而直接是一些业务处理，这样就需要我们整合起来到service中去，这样可以起到一个更好的开发与维护的作用，同时也是MVC设计模式中model层功能的体现

4 . Entity、Pojo、JavaBean和DTO有什么区别？

Entity：实体bean，一般是用于ORM对象关系映射，一个实体映射成一张表，一般无业务逻辑代码，有些优秀框架中修改entity会直接同步到数据库。

JavaBean：是一种Java语言写成的可重用组件，类必须是具体和公共的，并且具有无参数的构造器，可以把数据封装起来，把应用的业务逻辑和显示逻辑分离开，降低了开发的复杂程度和维护成本（说白了就是一种类的规范，符合这种规范的都可以叫JavaBean）

Pojo：简单的Java对象，实际就是普通JavaBeans，是为了避免和EJB混淆所创造的简称。

DTO：数据传输对象（Data TransferObject），是一种设计模式之间传输数据的软件应用系统。

5.模型类和VO、DTO、DO、PO分别是什么

VO（View Object）：视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。

DTO（Data Transfer Object）：数据传输对象，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，我泛指用于展示层与服务层之间的数据传输对象。

DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。
PO（PersistentObject）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。

模型层：
下面以一个时序图建立简单模型来描述上述对象在三层架构应用中的位置

用户发出请求（可能是填写表单），表单的数据在展示层被匹配为VO。
展示层把VO转换为服务层对应方法所要求的DTO，传送给服务层。 l
服务层首先根据DTO的数据构造（或重建）一个DO，调用DO的业务方法完成具体业务。
服务层把DO转换为持久层对应的PO（可以使用ORM工具，也可以不用），调用持久层的持久化方法，把PO传递给它，完成持久化操作。
对于一个逆向操作，如读取数据，也是用类似的方式转换和传递。

三层架构

三层由表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)组成。

1.表现层（web层）：包含JSP，Servlet等web相关的内容
  职责：①向用户展示特定的业务数据
     ②采集用户的信息和操作
  原则：用户至上，兼顾简洁

2.业务逻辑层（Service层）： 处理业务，不允许出现servlet中的request、response。
  职责：① 从UI中获取用户指令和数据，执行业务逻辑
     ②从UI中获取用户指令和数据，通过DAL写入数据源
     ③从DAL中获取数据，以供 UI 显示用
  机制：① UI –> BLL –> UI
     ② UI –> BLL –> DAL –> BLL –> UI

3.数据访问层（持久层）：封装了对数据库的访问细节。
  作用：跟数据源打交道
  职责：①执行对数据的操作（增删改查）
注意：其中 web层相当于mvc中的view，Service层和dao层相当于mvc中的modle。

4.数据对象层
  数据对象层包含了项目需要使用的数据对象，用数据对象来传递数据，它避免了各个层的交叉引用。
  一般一个表对应一个数据对象。

UI():主要是指与用户交互的界面。用于接收用户输入的数据和显示处理后用户需要的数据。

BLL:(业务逻辑层):UI层和DAL层之间的桥梁。实现业务逻辑。业务逻辑具体包含：验证、计算、业务规则等等。

DAL:(数据访问层):与数据库打交道。主要实现对数据的增、删、改、查。将存储在数据库中的数据提交给业务层，同时将业务层处理的数据保存到数据库。（当然这些操作都是基于UI层的。用户的需求反映给界面（UI），UI反映给BLL，BLL反映给DAL，DAL进行数据的操作，操作后再一 一 返回，直到将用户所需数据反馈给用户）