三层架构/MVC/MTV

在以前的时候，我总是把这三者混为一谈，总以为是不同语言或者不同环境条件下的称呼或者变种，后来我逐渐明白这是不一样的。

三层架构

web开发其实并不一定需要遵循某一个框架进行开发，其实上能够实现web服务就行，但是在长期的摸索跟探究过程中，前人根据自己的经验进行总结，得出依据某个框架或者某个模式进行开发是一个较为高效的过程。

界面层（表示层）:用户看的界面。用户可以通过界面上的组件和服务器进行交互
业务处理逻辑:处理业务逻辑的
数据访问层:操作数据存储文件

本质上这是一个线性结构，从上往下：

表示层请求数据，发送给业务逻辑层
业务逻辑层根据情况去数据访问层进行数据查询

从下往上：

数据访问层提交原始数据给业务逻辑层
业务逻辑层将处理后的数据提交给表示层

整个过程是一个线性结构从上至下的请求数据，数据从下往上进行返回

三层架构的优缺点

优点:
1、高内聚，低耦合
2、方便维护，易于扩展
3、开发人员可以只关注某一层，有利于分工协作，加快开发速度

缺点:
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
3、增加了代码量，增加了工作量

MVC

M-model模型: 数据存储层，和数据库打交道。
V-view视图: 视图层，用户看到并与之交互的界面，如由html元素组成的网页界面，或软件的客户端界面。
C-controler控制器: 控制层，控制器把视图层所给的指令用来检索数据层的数据，该层编写代码产生结果并输出。

这个模型的运行过程如下：

用户与人机交互输入信息到控制器
控制器将数据指令传递给业务模型
业务模型从数据库当中进行数据从存取
最后根据不同的业务逻辑选择不同的视图
视图给用户之后，用户再选择下一步操作

相比于三层模型，MVC没有直接与数据库进行交互，而是通过模型操控数据库，同时根据：用户->控制器->模型->视图->用户形成一个闭环。相比于三层结构的层层深入再返回，这就不再是一个线性结构，而是一个基于用户操作三角闭环结构。

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.视图与控制器间的过于紧密的连接并且降低了视图对模型数据的访问，视图与控制器是相互分离，但却是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。