所以,是的,这就是我所理解的。
- Servlet只是一个中介,负责找出请求中的参数是什么意思。这些参数被提供给
.java
文件。它只是一个中介 .java
文件是执行业务逻辑的模型- View是将进行演示的 JSP
我做对了吗?
所以,是的,这就是我所理解的。
.java
文件。它只是一个中介.java
文件是执行业务逻辑的模型我做对了吗?
模型视图控制器模式并不特定于 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 类文件规范即可。
其次,虽然 JSP 长期以来一直是 Java Servlet 技术中的默认视图技术,但它远非唯一。其他技术包括 Facelets、Velocity、Freemarker 等,也没有什么可以阻止您在没有专用视图技术的情况下将数据直接写入来自控制器的请求(尽管通常不建议这样做)。
基本上,MVC 代表的是一个系统,其中有用于业务逻辑(M)、视图技术(V)和将事物联系在一起的控制器的单独代码。在组织良好的 MVC 架构中,M 部分被很好地封装,相同的业务逻辑也可以通过其他渠道(例如 Web 服务、直接库访问等)执行。此外,应该可以通过外部配置来切换视图技术,而无需编辑实际的控制器逻辑。
我建议您阅读Spring MVC 框架的文档,据我所知,它是目前最强大(并且也易于使用)的 MVC 框架,并且工具支持也很棒(在 InteliJ Idea 或基于 Eclipse 的 SpringSource 工具套件)。
当您谈论 MVC 时,所有三个层都应该彼此分开。在网络应用程序中:
1:控制器应负责处理用户请求,然后过滤并执行适当的操作,然后将生成的响应转发给客户端。
2:模型由您的业务逻辑、bean 和 Pojo 类组成。这应该处理您的逻辑,执行一些操作并将生成的结果呈现给某种持久对象或 DTO。
3:视图由您的GUI、一些表示逻辑组成,它应该与您的后端分离,最终您向客户显示结果的封装形式,即客户实际需要的结果。
MVC有两种类型:MVC1(Push-MVC)和MVC2(Pull-MVC)
Pull-MVC 和 Push-MVC 可以更好地理解视图层如何获取数据,即要渲染的模型。在 Push-MVC 的情况下,数据(模型)由控制器构造并提供给视图层,方法是将其放入范围变量(如请求或会话)中。典型的例子是 Spring MVC 和 Struts1。另一方面,Pull-MVC 将通常在 Controller 中构建的模型数据保存在一个公共位置,即在动作中,然后由视图层呈现。Struts2 是一个基于 Pull-MVC 的架构,其中所有数据都存储在 Value Stack 中,并由视图层检索以进行渲染。