Servlets的MVC架构工作原理

Question

所以，是的，这就是我理解的。

• Servlet只是一个中介，负责找出请求中参数的含义。这些参数会被传递给.java文件。它只是一个中介。
• .java文件是模型(Model)，用于执行业务逻辑。
• 视图(View)是将呈现结果的JSP。

我的理解正确吗？

- An SO User

---

你缺少了一些东西，即ValueObjects JSP<->VO<->Servlet<->VO<->Model。 - TheWhiteRabbit

现在我开始忘记了.. 哈哈。你刚才说什么？ - An SO User

你的模型与BusinessObject绑定，因此不建议直接在Controller和View中使用它，应该使用中间的DataTransferObjects或ValueObjects来传递数据。 - TheWhiteRabbit

Answer 1

“模型视图控制器”模式不是特定于Java或Servlet技术的。有许多非Java MVC实现，而在Java中，也有非Servlet实现（Swing就是一个例子）。

在Java中，使用基于Servlet的MVC时，通常会使用MVC框架。这里有两个主要类别：基于动作和基于组件，区别在于基于动作的框架独立监听每个已注册的URL，而基于组件的框架保留组件树并维护服务器端状态。

基于动作的框架有Spring MVC、Struts 1+2、Stripes、Play等。基于组件的框架有Wicket、JSF 1＆2、Tapestry等。

您的图表接近真相，但存在一些微妙的误解。

首先，谈论.java文件没有意义。Java源文件对于部署的Web应用程序完全无关，它仅使用编译的.class文件，并且可以使用许多不同的语言编程JavaVM，因此应用程序不关心.class文件是否从Java、Scala、Groovy、JRuby、Clojure、AspectJ或其他任何内容编译而成，只要它们符合Java Class File规范即可。

其次，虽然JSP一直是Java Servlet技术中默认的视图技术，但它并不是唯一的选择。其他技术包括Facelets、Velocity、Freemarker等，而且你也可以在没有专门视图技术的情况下直接将数据写入请求控制器（尽管这通常不可取）。

基本上，MVC代表的是一个系统，其中有单独的代码用于业务逻辑（M）、视图技术（V）和将它们联系起来的控制器。在一个良好组织的MVC架构中，M部分被封装得很好，以至于相同的业务逻辑也可以通过其他渠道执行（例如Web服务、直接库访问等）。此外，应该可以通过外部配置来切换视图技术，而无需编辑实际的控制器逻辑。

我建议您阅读Spring MVC框架的文档，据我所知，它是最强大（也易于使用）的MVC框架，并且工具支持也非常好（无论是InteliJ Idea还是基于Eclipse的SpringSource Tool Suite）。

- Sean Patrick Floyd

Answer 2

当谈论MVC时，三个层应该相互分离。

在Web应用中：

1. 控制器(Controller)负责处理用户请求，过滤并执行适当的操作，然后将生成的响应转发给客户端。

2. 模型(Model)包含业务逻辑、bean和POJO类。它应该处理您的逻辑，执行一些操作，并将生成的结果呈现给某种持久性对象或DTO。

3. 视图(View)包含GUI、一些演示逻辑，应该与后端分离，最终向客户端显示结果的封装形式，即客户端实际需要的内容。

引用块：

有两种MVC架构：MVC1（Push-MVC）和MVC2（Pull-MVC）。

Pull-MVC和Push-MVC更好地理解了视图层如何获取数据，即从模型渲染。在Push-MVC的情况下，控制器构建并通过将其放入作用域变量（例如请求或会话）来提供视图层所需的数据（模型）。典型的例子是Spring MVC和Struts1。另一方面，Pull-MVC将通常在控制器中构建的模型数据存储在一个公共位置中，即在动作中，然后由视图层呈现。Struts2是一种基于Pull-MVC的体系结构，在这种架构中，所有数据都存储在值堆栈中，并由视图层检索以进行呈现。

- arvin_codeHunk