三层架构和 MVC 模式的区别与联系

概述

对于初学者来说，刚刚接触这两个概念，很有可能容易混淆，误以为是一个事物的两种叫法。但深入了解后会发现，二者的构建大有不同。所以，“混淆”未必就是一件坏事，当你从“混淆”中走出来时，往往会对二者有一个比较深刻的认知。

三层架构

简介

三层架构是从整个业务应用角度对程序的划分，其分层逻辑来源于“高内聚，低耦合”的思想。三层分别为：表现层（Web层），业务逻辑层，数据访问层（持久化层）。

附：

• 内聚性：又称块内联系。指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素（语名之间、程序段之间）联系的越紧密，则它的内聚性就越高。
• 耦合性：也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。

各层解析

ps：为了能够使大家更为形象地理解，在此就举个小栗子——搭积木。

• 各层的定义
  
  • 表现层（Web层）：通俗说就是用户所能看到的直观的界面。其作用就是接收用户提交的请求数据，以及将程序对用户请求所产生的响应数据反馈给用户。目的就是为用户提供可交互的操作界面。所以，表现层就像已经搭好的积木。
  • 业务逻辑层：简单讲就是“具体问题，具体分析”。它根据用户的不同请求而做出不同响应的处理。可以说是对数据层的一种整合方式。所以，就如同每个人会根据自己的喜好搭建不同的积木一样，业务逻辑层代表的就是搭积木的方式。
  • 数据访问层（持久化）：它只是提供对数据库操作的多种途径。不同的数据就好比形状各异的积木，而数据访问层就好比取出或放回这些积木的动作。
• 各层联系
  依旧是搭积木的小栗子。
  流程：根据积木成型的图纸（表现层），我们会设计该怎样去搭建（业务逻辑层），然后就开始取积木（数据访问层）进行搭建，当我们完成设计流程的时候，积木也就成型了。

项目中的开发流程

不知道大家有没有从上述的“各层联系”中，尝到了一丝丝“嵌套”的味道。

所以我的建议是——当你对流程有了整体的把握之后，建议从最内层开始设计并实现。

MVC 模式

简介

MVC 是 Model-View-Controller 的简称，即模型-视图-控制器。它属于设计模式的范畴，就如同其他设计模式一样，模式的出现就是为了对某种功能的优化，而MVC模式可以看做是对三层架构中表现层的一种细分优化。
MVC 分层有助于管理复杂的应用程序，因为您可以在一个时间内专门关注一个方面。例如，可以在不依赖业务逻辑的情况下专注于视图设计。同时也让应用程序的测试更加容易。

各模块解析

• 各模块定义
  
  • 模型（Model）：封装的是数据源和所有基于对这些数据的操作。在一个组件中，Model往往表示组件的状态和操作状态的方法。
  • 视图（View）：封装的是对数据源Model的一种显示。一个模型可以由多个视图，而一个视图理论上也可以与不同的模型关联起来。
  • 控制器（Control）：封装的是外界作用于模型的操作。通常，这些操作会转发到模型上，并调用模型中相应的一个或者多个方法。一般Controller在Model和View之间起到了沟通的作用，处理用户在View上的输入，并转发给Model。这样Model和View两者之间可以做到松散耦合，甚至可以彼此不知道对方，而由Controller连接起这两个部分。
• 各模块联系
  

附：框架和设计模式的区别

引自百度百科

有很多程序员往往把框架模式和设计模式混淆，认为MVC是一种设计模式。实际上它们完全是不同的概念。
框架、设计模式这两个概念总容易被混淆，其实它们之间还是有区别的。框架通常是代码重用，而设计模式是设计重用，架构则介于两者之间，部分代码重用，部分设计重用，有时分析也可重用。在软件生产中有三种级别的重用：内部重用，即在同一应用中能公共使用的抽象块;代码重用，即将通用模块组合成库或工具集，以便在多个应用和领域都能使用；应用框架的重用，即为专用领域提供通用的或现成的基础结构，以获得最高级别的重用性。
框架与设计模式虽然相似，但却有着根本的不同。设计模式是对在某种环境中反复出现的问题以及解决该问题的方案的描述，它比框架更抽象；框架可以用代码表示，也能直接执行或复用，而对模式而言只有实例才能用代码表示;设计模式是比框架更小的元素，一个框架中往往含有一个或多个设计模式，框架总是针对某一特定应用领域，但同一模式却可适用于各种应用。可以说，框架是软件，而设计模式是软件的知识。
简而言之：框架是大智慧，用来对软件设计进行分工；设计模式是小技巧，对具体问题提出解决方案，以提高代码复用率，降低耦合度。