[开发测试]MVC模式与三层架构

概述

广义上来说，MVC模式与三层框架是没有联系的，但是在三层架构中，表示层通常会使用MVC模式进行构建，经常使用的MVC框架有Spring MVC，Struts等。

系统架构

指整合应用系统程序大的结构，早期计算机行业没有这个概念，随着互联网的兴起，在05年提出这一词（微软C#上市的一年，利用petsshop做了一个案例介绍三层架构，自此有了架构的概念）。
系统间的复杂度等于系统间的耦合度，系统架构均是为了降低系统模块间的耦合度。

高内聚，低耦合

• 一个类只做一件事（高内聚）：日期管理工具类不应该出现四则运算相关的事（数学工具类），体现了最少知识原则。
• 一个方法只做一件事：体现了单一职责原则。
• 写只写一次。

MVC

• Model（模型）：最底下的一层，是核心的“数据层”（Model），也就是程序需要操作的数据或信息。
• View（视图）：最上面的一层，是直接面向最终用户的“视图层”（View），是提供给用户的操作界面，是程序的外壳。
• Controller（控制）：中间的一层，就是“控制层”（Controller），负责根据用户从“视图层”输入的指令选取“数据层”中的数据，然后对其进行相应的操作并产生最终结果。

概述

• 是一种设计模式，它分离了表现与交互。
• MVC模式是应用于三层架构中视图层的模式，它不属于设计模式（23种）。

三个核心部件

• Model（模型）是应用程序中用于处理应用程序数据逻辑的部分，通常负责在数据库中存取数据。
• View（视图）是应用程序中处理数据显示的部分，通常是依据模型数据创建的。
• Controller（控制器）是应用程序中处理用户交互的部分，通常负责从视图读取数据，控制用户输入，并向模型发送数据。

优点

1. 耦合性低
由于运用MVC的应用程序的三个部件是相互独立，改变其中一个不会影响其它两个，所以依据这种设计思想能构造良好的松耦合的构件。
2. 重用性高
因为MVC模式允许使用不同样式的视图来访问同一个服务器端的代码，而模型返回的数据没有进行格式化，这样应用于模型的代码只需写一次就可以被多个视图重用，所以实现了最大化地重用代码。
3. 成本低
MVC模式使开发和维护用户接口的技术含量降低。
4. 部署快
使用MVC模式使开发时间得到很大的缩减，它使程序员集中精力于业务逻辑或表现形式上。
5. 可维护性高
分离视图层和业务逻辑层也使得WEB应用更易于维护和修改。

缺点

1. 没有明确的定义
要完全理解MVC并不是很容易，而且模型和视图的严格分离也给调试应用程序带来了一定的困难，每个构件在使用之前都需要经过彻底的测试。
2. 不适合中小规模的应用程序
花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。
3. 增加系统结构和实现的复杂性
对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
4. 视图与控制器间的过于紧密的连接
视图与控制器是相互分离，但却是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
5. 视图对模型数据的低效率访问
依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
6. 一般高级的界面工具或构造器不支持该模式
为适应MVC需要，改造这些工具和建立分离部件的代价是很高的，会造成MVC使用的困难。

MVC完整流程

1. 所有的终端用户请求被发送到控制器。
2. 控制器依赖请求，选择加载对应的模型，并把模型附加到对应的视图。
3. 附加了模型数据的最终视图作为响应发送给用户。

MVC举例一：最典型的MVC就是JavaBean+Serlvet+JSP模式

JavaBean作为模型，既可以作为数据模型来封装业务数据，又可以作为业务逻辑模型来包含应用的业务操作。其中，数据模型用来存储或传递业务数据，而业务逻辑模型接收到控制器传过来的模型更新请求后，执行特定的业务逻辑处理，然后返回相应的执行结果。
JSP作为表现层，负责提供页面为用户展示数据，并在适当的时候向控制器发出请求，请求模型进行更新。
Serlvet作为控制器，用来接收用户提交的请求，然后获取请求中的数据，将之转换为业务模型需要的数据模型，然后调用业务模型相应的业务方法进行更新，同时根据业务执行结果来选择要返回的视图。

MVC举例二：基于MVC的轻量级的Web应用框架——Struts2

1. 控制器——FilterDispatcher
用户请求首先到达前端控制器FilterDispatcher，FilterDispatcher根据用户提交的URL和struts.xml中的配置，来选择合适的动作（Action）。FilterDispatcher其实是一个过滤器（Filter是Servlet规范中的一种web组件），它是Struts2核心包里已经做好的类，不需要我们去开发，只是要在项目的web.xml中配置一下即可。FilterDispatcher体现了J2EE核心设计模式中的前端控制器模式。
2. 动作——Action
用户请求被FilterDispatcher分发到合适的Action对象之后，Action会把用户请求中的参数组装成合适的数据模型，再调用相应的业务逻辑进行真正的功能处理，并获取下一个视图展示所需要的数据。Struts2的Action相比于其它Web框架的动作处理，它实现了与Servlet API的解耦，即Action不用直接引用HttpServletRequest与HttpServletResponse等接口，从而使得Action的单元测试更加简单，而且强大的类型转换也使得我们少做了很多重复的工作。
3. 视图——Result
视图结果用来把动作中获取到的数据展现给用户。在Struts2中有多种结果展示方式，比如Jsp、FreeMarker等，而且各种视图结果在同一个工程里面可以混合出现。

• Model：模型，承载数据，并对用户提交请求进行计算的模块
  • 数据模型（数据承载Bean）：指实体类（Entity），专门用于承载业务数据的，如Student、User等。
  • 业务模型（业务处理Bean）：指Service或Dao对象， 专门用于处理用户提交请求的。
• Controller：控制器，用于将用户请求转发给相应的 Model 进行处理，并根据 Model 的计算结果向用户提供相应响应
  • 最开始用Servlet（服务器小程序）开发，Servlet既要处理业务逻辑，又要处理页面展示。
  • 后来出现JSP（Java Server Page，Java服务器页面）处理页面展示，因为JSP就是Servlet，所以JSP也可以使用脚本<%%>处理业务逻辑，但是为了降低耦合度所以不用，而JSP能把Servlet分离出来，所以它是一门技术，类似于C#（.net）的aspx（.net是开发平台，C#则是.net开发平台的一门程序设计语言，.net开发平台还可以用vb、js、C/C++等语言进行开发，.net平台提供了很多API，可以把它理解成CPU，它提供了很多指令，它的指令可以供外部调用从而组成一个程序、一个软件）。
    • Java > .jsp
    • C# > .aspx
    • PHP > .php
• View：视图，为用户提供使用界面，与用户直接进行交互

MVC架构程序的工作流程

1. 用户通过View页面向服务端提出请求，可以是表单请求、超链接请求、AJAX请求等。
2. 服务端Controller控制器接收到请求后对请求进行解析，找到相应的Model对用户请求进行处理。
3. Model处理后，将处理结果再交给Controller。
4. Controller在接到处理结果后，根据处理结果找到要作为向客户端发回的响应View页面，页面经渲染（数据填充）后，再发送给客户端。

MVC，MVP，MVVM

都是视图层的模式

• M，Model 模型，分两种，业务处理模型是数据承载模型，业务处理模型将视图层与三层架构联系起来。
• V，视图，所有界面都是视图，不光是html，桌面应用也是视图，移动应用，如手表，手机，包括电视等都是视图，因为那里有交互。
• C 控制器，处理请求做分发。
  以上各种特点都以表明这种模式是视图层需要的，但缺点是耦合度太高，灵活性差，同步并阻塞，效率也低，于是根据关注度分离原则，我们要彻底分离出这一层，所以衍生出了MVP，MVVM模式，也就是所谓的前后分离，更进一步的解偶，让前后协作更加通畅，Web不过就是B/S架构下的一种开发方式。

垂直架构

是MVC+ORM，不单是MVC。

三层架构（3-tier architecture）

就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL），区分层次的目的即为了“高内聚，低耦合”的思想。

• 表现层（User Interface）：就是展现给用户的界面。
• 业务逻辑层（Business Logic Layer）：也被称为领域层，它与系统所应对的领域（Domain）逻辑有关，负责实现核心业务逻辑，事务控制也在这一层实现。
• 数据访问层（Data Access Layer）：也被称为持久层，主要负责对数据库的访问来读取数据和传递数据，实现对数据的持久化。

在Java Web项目中：

• Web层——表现层
• Service层——业务逻辑层
• DAO层(Data Access Object)——数据访问层

优点

1. 开发人员可以只关注整个结构中的其中某一层。
2. 可以很容易的用新的实现来替换原有层次的实现。
3. 可以降低层与层之间的依赖。
4. 有利于标准化。
5. 利于各层逻辑的复用。
6. 结构更加的明确。
7. 在后期维护的时候，极大地降低了维护成本和维护时间。

缺点

1. 降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2. 有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
3. 增加了开发成本。
   为了更好的降低各层间的耦合度，在三层架构程序设计中，采用面向抽象编程，即上层对下层的调用，是通过接口实现的，而下层对上层的真正服务提供者，是下层接口的实现类，服务标准（接口）是相同的，所以服务提供者（实现类）可以更换，这就实现了层间解耦合

服务层可以叫Service或Manager等（称呼没有定义），但是Java称服务层为Service，这是约定。

四层架构

就是增加了信息资源层，此层主要服务于资源的存储。