Building Layered Architecture in Just 3 Minutes: Final Part
In this tutorial, the author exposes employee data to UI, the classic MVC pattern using Spring Boot.
Join the DZone community and get the full member experience.
Join For FreeI am sure that you have enjoyed the part1 where in just the blink of an eye we set up an in-memory database, created a Repository class using Spring Data JPA, and inserted data using initDataloader by Spring boot.
In this tutorial, we will expose those employee data to UI, The Classic MVC pattern using Spring boot.
The Service Part
In my previous article, I created an EmployeeRepository interface, and Spring Boot provided its implementation at runtime. Now, I want this data to be guided to the Service Layer. To achieve that, I need to inject that Repository to Service layer and define the CRUD methods, which are doing nothing but calls the Repositories CRUD methods. Now, you may be wondering, the EmployeeRepository interface is empty and it extends CRUDRepository where you can only find the declaration of CRUD methods. The question is, where are the implementations?
Again, the answer is Spring Boot on the runtime. It creates an implementation class that has all the CRUD method implementations. Interesting, isn't it? We just declare an interface and a container creates all the stuff for us, and we save lots of our precious time, get rid of silly mistakes, etc. Really an IOC (Inversion of Control).
Let's see what the service part looks like, and please note for simplicity that I print the messages in the console using Sysout. But in the real project, don't ever do this. Use Logger always.
package com.example.layerdArchitechture.service;
import java.util.Optional;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import com.example.layerdArchitechture.entity.Employee;
import com.example.layerdArchitechture.repository.EmployeeRepositiry;
@Service
public class EmployeeService {
@Autowired
EmployeeRepositiry repo;
public Employee addEmployee(Employee emp) {
emp = repo.save(emp);
System.out.println("Employee saved::" + emp);
return emp;
}
public Optional < Employee > findEmployeeById(Long empId) {
Optional < Employee > emp = repo.findById(empId);
System.out.println("Employee found::" + emp);
return emp;
}
public Iterable < Employee > findAllEmployee() {
return repo.findAll();
}
public void deleteEmployeeById(Employee emp) {
repo.delete(emp);
System.out.println("Employee deleted::" + emp);
}
}
Our service Layer is ready and now I need a controller part that will act as a delegator and takes data from UI to send it to Service and Vice versa. I personally recommend using Controller as a thin layer, which just porting data from UI to service and service to UI and maybe doing some data format conversion stuff and nothing more than that.
Before showing you the code of the controller, let me remind you I have not used a proper Spring controller, which forwards the response to a view. Rather, I use a RestController, which directly delivers the response payload in JSON/XML format based on the Produces property. By default, it is JSON.
In Controller, we map the URL pattern to a controller method bind any data coming from a form into a Model the "M" part of MVC.
Let's see the code.
package com.example.layerdArchitechture.controller;
import java.util.Optional;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import com.example.layerdArchitechture.entity.Employee;
import com.example.layerdArchitechture.service.EmployeeService;
@RestController
public class EmployeeController {
@Autowired
EmployeeService service;
@RequestMapping("/TCS/employees")
public Iterable<Employee> findAllEmployee() {
return service.findAllEmployee();
}
@RequestMapping("/TCS/employee/{id}")
public Employee findbyId(@PathVariable Long id) {
Optional<Employee> emplyoeeContainer = service.findEmployeeById(id);
return emplyoeeContainer.isPresent()?emplyoeeContainer.get():null;
}
@RequestMapping("/TCS/employee/addDemoEmployee")
public Employee addEmployee() {
Employee emp = new Employee();
emp.setName("Demo Demo");
emp.setSex("M");
emp.setAddress("Demo");
return service.addEmployee(emp);
}
@RequestMapping("/TCS/employee/delete/{id}")
public String delete(@PathVariable Long id) {
Optional<Employee> emp = service.findEmployeeById(id);
if(emp.isPresent()) {
service.deleteEmployeeById(emp.get());
return "deleted Successfully";
}
return "Employee Not Exists, Not able to delete";
}
}
If you look at the Controller class, you can see that I autowired the service class and then wrote CRUD methods (also map them with Url pattern) as a wrapper, which internally calls the Service Wrapper method and that calls the Spring Boot's Repository Implementation class.
Now if I run the Spring Boot application class and hit the following URL in the browser...
http://localhost:8080/TCS/employees
...I can see the following response in the browser in JSON format.
[
{
"id": 1,
"name": "Shamik Mitra",
"address": "BagBazar",
"sex": "M"
},
{
"id": 2,
"name": "Samir Mitra",
"address": "BagBazar",
"sex": "M"
},
{
"id": 3,
"name": "Swastika Basu",
"address": "Baranagar",
"sex": "F"
}
]
Hope you enjoyed the post.
Published at DZone with permission of Shamik Mitra, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments