1. Data Access Services
| Version | Data | Notes |
|---|---|---|
| Version 1.0 | December 2022 | Initial version |
| Version 2.0 | September 2023 | Haetoas |
| Version 3.0 | October 2024 | Translations |
© Joan Gerard Camarena Estruch
- These materials are based on previous years notes created by Joan Gerard Camarena and Jose Alfredo Murcia.
- Special thanks to Loren Diaz de Haro to share his material and code samples.
1. Introduction. Data Access Services
A servlet is an application that runs on an server, prepared to respond to http requests. Later we have JSP (Java Server Pages), which allow combining HTML/XML elements with Java code fragments to generate content dynamically. We must launch an application server and add the application to run it and serve it as another page.
We can use Servlets to write a web application, but there are many intrinsic details to control: validation, REST, request / response body for JSON, form binding, etc. This implies that much of our code is devoted to controlling the lower layers of communication.
With the Spring framework, it really uses servlets, but it frees the programmer from such a heavy task, managing it automatically. This allows the user to focus on the logic of the application, without having to manage the lower levels of communications. In addition, Spring Boot is defined as a Spring accelerator, allowing us to indicate a series of conventions (behaviors) that perform heavy file configuration tasks for us. Finally, Spring Boot incorporates an embedded web server (usually Tomcat)
The term framework or if we try to force its translation into Spanish Marco de trabajo provides us with a set of rules and tools designed to increase the speed of application development
2. MVC
The Model View Controller (MVC) is an architecture for application development that separates data, interface, and control logic into layers.
The operation is as follows:
- The user is using the client application (usually a browser or client), and makes a request through the http protocol, also known as an HTTP_REQUEST. These requests are received by the controller module. The controller manages a list of operations or events that it can process, determined by its own protocol.
- In the case of a request that requests a query or modification of the data, we pass the parameters provided in the request to the model layer. This layer accesses the data, performing steps 3 and 4 through DBMS operations. The Model is now in a position to give an answer.
- Consult the database.
- Database query recovery.
- The model transfers the obtained result set to the view.
- The view is responsible for receiving the data and presenting or formatting it appropriately.
- The controller returns the presentation generated by the view (which will typically be dynamic HTML) to the client application, via the HTTP_RESPONSE request.
3. REST
The REST (Representational State Transfer) model allows us to provide our server with a service to easily retrieve and manipulate data on the server. In this model, the part of the view is delegated to the client, leaving the controller and the model on the server. In this model, we will highlight among others:
- The protocol follows the stateless client/server model, just like http, a request will only respond according to the information received in the same request.
- Support of CRUD operations, through the equivalent http specifications: GET (query), POST (create), PUT (modify) and DELETE (delete)
- Arrangement of the HATEOAS model (Hypermedia As Engine Of The Application State). This principle allows hyperlinks as a resources to be included in responses.
In MVC, and in a simplified way, it would be to remove the layer from the view and return the data processed by the model. Usually REST servers return data in JSON format