MVC模式（三层体系结构）

（模型-视图-控制器）是软件工程中的软件体系结构模型，它将软件系统分为三个基本部分: 模型，视图和控制器.

MVC模型由Trygve Reenskaug于1974年首次提出. 它是Xerox PARC在1980年代为编程语言Smalltalk发明的软件设计模型. MVC模式的目的是实现动态程序设计，简化程序的后续修改和扩展，并可以重用程序的特定部分. 另外，该模式通过简化复杂性使程序结构更直观. 该软件系统将其基本部分分开，并为每个基本部分提供其功能. 可以根据自己的知识对人员进行分组:

MVC是一种强制将应用程序的输入，处理和输出分开的设计模式. 使用MVC的应用程序分为三个核心组件: 模型，视图和控制器. 他们每个人都处理自己的任务.

视图是用户查看并与之交互的界面. 对于旧的Web应用程序，视图是由HTML元素组成的接口. 在现代Web应用程序中，HTML在视图中仍然发挥着重要作用，但是一些新技术层出不穷，其中包括Macromedia Flash和一些标记语言，例如XHTML，XML / XSL，WML和Web服务. 如何处理应用程序的界面变得越来越具有挑战性. MVC的一大优点是它可以为您的应用程序处理许多不同的视图. 实际上，视图中没有实际处理. 无论数据是存储还是从员工列表中查看，它都是一种输出数据并允许用户对其进行操作的方法. 该模型表示企业数据和业务规则. 在MVC的三个组件中，模型具有最多的处理任务. 例如3层结构测试3层结构测试，它可以使用诸如EJB和ColdFusion组件之类的组件对象来处理. 模型返回的数据是中性的，也就是说，该模型与数据格式无关，因此模型可以为多个视图提供数据. 由于应用于模型的代码只能由多个视图重复使用一次，因此减少了代码重复. 控制器接受用户的输入并调用模型和视图以完成用户的需求. 因此，当单击网页中的超链接并发送HTML表单时，控制器本身不会输出任何内容，也不会进行任何处理. 它仅接收请求，并确定要调用哪个模型组件来处理该请求，然后确定要使用哪个视图来显示模型处理返回的数据. 现在我们总结一下MVC的处理过程. 首先，控制器接收用户的请求并决定应调用哪个模型进行处理，然后该模型使用业务逻辑来处理用户的请求并返回数据，最后，控制器使用相应的视图对模型进行格式化以返回数据通过表示层呈现给用户.

1. 开发人员只能专注于整个结构中的一层；

2. 很容易用新的实现方式替换原来的实现方式；

3，可以减少各层之间的依赖性；

4. 有利于标准化；

5. 促进所有级别的逻辑重用.

（1）增加了系统结构和实现的复杂性. 对于简单的界面，请严格遵循MVC并分离模型，视图和控制器，这将增加结构的复杂性，并可能生成过多的更新操作并降低操作效率.

（2）视图和控制器之间的连接太紧. 视图和控制器彼此分离，但是它们确实是紧密相关的组件. 视图没有控制器，视图的应用非常有限，反之亦然，这阻止了视图的独立重用.

（3）视图无法有效访问模型数据. 根据模型操作界面，可能需要多次调用该视图才能获得足够的显示数据. 不必要地频繁访问未更改的数据也会损害操作性能.

了解真正的所谓“框架”

我们想要什么

在回顾我们的代码编写历史之后，我们回头看看，我们想要什么？

无论使用JSP，Struts1还是Struts2，我们至少都需要一些必要的元素（如果没有这样的元素，也许我真的不知道该程序的外观）:

1. 数据

在此示例中，它们是名称和密码. 它们共同构成了该计划的核心载体. 实际上，我们经常有一个User类来封装名称和密码，这将使我们的程序更加面向对象. 无论如何，数据将散布在整个程序中，并成为程序的核心.

2. 页面显示

在此示例中，它是login.jsp. 没有此页面，就无法谈论所有请求，验证和错误显示. 在页面上，我们需要使用HTML来呈现我们需要显示的所有数据. 同时，我们还需要完成某些页面逻辑，例如错误显示，分支判断等.

3. 处理特定业务的地方

在不同阶段，处理特定业务的地点不同. 最初使用JSP和Servlet，后来使用Struts1或Struts2 Action.

上述必备元素在不同时代被赋予了不同的表达形式，有些受到时代的束缚，它们的表达形式非常落后，有些不再使用. 但是，撇开这些外部表现，我们可以发现这是我们已经熟悉的MVC吗？

数据————模型

页面显示————视图

处理特定业务的场所————控制权

因此，框架并不重要，概念为王. 只要您对MVC的概念有深刻的了解，该框架就只是您的jar包.

MVC的概念实际上就是这么简单. 这些概念已经渗透到我们的心中，而我们缺乏的是挖掘其本质

来吧. 让我们看一下下面的图片，它是关于已经流行了很多年的MVC模型的图片:

在此图中，MVC的三个框架执行其职责，并且结构清晰明了. 但是我认为这张图片忽略了一个问题，那就是数据在移动. 一旦数据在视图和控制层中移动，就会出现很多问题:

1. 数据从View层传递到Control层，如何将扁平字符串变成生动的Java对象

2. 当数据从View层传递到Control层时，如何方便地验证数据格式和内容？

3. 数据从控制层传递到视图层，以及如何以各种形式在页面上显示各种Java对象

4. 如果尝试将数据请求从“视图”层发送到“控制”层，那么如何知道正在调用的类和方法？ Http请求如何与控制层中的Java代码建立关系？

此外，控制层似乎没有想象中的那么简单，因为作为控制器，它至少需要处理以下问题:

1. 作为调用逻辑处理程序的外观，如果逻辑处理程序异常，应该如何处理？

2. 关于逻辑处理的结果，我们需要做什么处理才能满足丰富的前端显示需求？

一个接一个提出的问题是基于对MVC基本概念的挖掘. 因此，在编写程序时需要一一解决这些问题. 话虽如此，本文开头提出的问题应该有一个答案: 该框架的诞生是为了解决Web开发中遇到的另一个问题. 设计了不同的框架来解决不同的问题，但是对于程序员来说，它们只是jar包. 对框架优缺点的评论也完全取决于其对问题解决程度和解决方案优雅程度的评论. 因此，不要为了学习框架而学习框架，而是要学习解决问题的框架，这是程序员学习的正确方法.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-287034-1.html