How MVC Architecture Works for Servlets
So yes, this is what I figured out.
- The Servlet is just an intermediary responsible for figuring out what the parameters in the request mean. These parameters are passed to the file
.java
. This is a simple intermediary. -
.java
file is a Model that executes business logic - View is the JSP that will execute the presentation
Did I understand correctly?
source to share
The Model Model controller pattern is not specific to Java technology or Servlet. There are many non-Java MVC implementations and there are non-Servlet implementations in Java (Swing example).
In Java, when using servlet based MVC, it is usually the MVC framework that is used. There are two main categories here: action-based and component-based, with the difference being that action-based frameworks listen to each registered URL independently, while component-based frameworks maintain the component tree and maintain server-side state.
Action-based frameworks are Spring MVC, Struts 1 + 2, Stripes, Play, etc. Component based frameworks are Wicket, JSF 1 & 2, Tapestry, etc.
Your diagram is approaching the truth, but there are a few subtle misconceptions.
First, it doesn't make sense to talk about .java files. Java source files are completely irrelevant to the deployed web application, it only uses compiled .class files, and JavaVM can be programmed in different languages, so the application doesn't care if the .class files were compiled from Java, Scala, Groovy. JRuby, Clojure, AspectJ, or whatever as long as they conform to the Java Class file specification.
Second, while JSP has long been the default browsing technology in Java Servlet technology, it is far from the only one. Other technologies include Facelets, Velocity, Freemarker, and so on, and there's nothing to stop you from writing data directly to a request from a controller without a dedicated viewer (although this is usually impractical).
Basically, what MVC stands for is a system that has separate code for business logic (M), view technology (V), and a controller that ties everything together. In a well-organized MVC architecture, the M part is so well encapsulated that the same business logic can also be executed through other channels (e.g. web services, direct library access, etc.). In addition, it should be possible to switch view technologies via configuration externally without editing the actual controller logic.
I would advise you to read the docs for Spring MVC framework , as far as I know these are the most robust (as well as easy-to-use) MVCs and tooling support is great too (either in InteliJ Idea or Eclipse based SpringSource Tool Suite) ...
source to share
When you talk about MVC, all three layers must be separated from each other. In the web app:
1: The controller should be responsible for handling the user's request, then filtering and performing appropriate actions, and then forwarding the generated response to the client.
2: The model consists of your business logic, beans and Pojo classes. It should touch you with logic, perform some operation and output the generated result to some persistent object or DTO.
3: The view is made up of your GUI, some presentation logic, it has to be decoupled from your end user, you end up showing the encapsulated form of the result to your client, which is what the client actually needs.
There are two types of MVC: MVC1 (Push-MVC) and MVC2 (Pull-MVC)
Pull-MVC and Push-MVC are better understood by how the presentation layer receives the data, i.e. the model to render. In the case of Push-MVC, the data (Model) is built and passed to the presentation layer by Controllers, placing it in scope variables such as request or session. Typical example is Spring MVC and Struts1. Pull-MVC, on the other hand, puts model data, which is usually built in controllers, stored in a common location, that is, in activities, which are then rendered using a view layer. Struts2 is a Pull-MVC based architecture where all data is stored in the Value Stack and retrieved using the presentation layer for rendering.
source to share