Conteúdo do Curso
Java Data Manipulation with Hibernate
Java Data Manipulation with Hibernate
Implementing the `Role` Entity
Since we want to make our employee management project correct, we should pay attention to one detail. Just to remind you, here's the Employee
entity we're working with:
As you can see, it's all good with it, but I don't like that the position
is just a string value. It would be more correct to create a separate "Role" table in the database and assign the employee an ID of the role from this database. For example, initially, we will have roles such as Software Engineer, Project Manager, Designer, and System Analyst.
These roles should be placed in a separate table, and instead of the position
field, we will have the roleID
field.
To do this, we need to do 3 things:
- Delete the
position
column; - Create the
Role
table; - Create a column in the
Employees
table that will be a foreign key forRole
.
Here's the SQL query to do this:
After such manipulations, the Employees
table will look like this:
The Role
table will look like this:
As you can see, we have added the necessary values to the Role
table. You may have also noticed that we have empty rows in the department_id
and role_id
columns. We will fill them through the code later on. Right now, we need to implement the Role
entity and also edit the Employee
entity accordingly.
Let's start with the Role
entity:
There's no need to comment much, as this is a standard entity without any innovations.
Now, we need to add this class to the mapping. To do this, we'll add this line to the hibernate.cfg.xml
file:
This is done so that Hibernate automatically detects this entity, saving us the trouble of specifying these classes every time we create a SessionFactory
.
Now let's see how we can properly edit the Employee
entity to establish a unidirectional relationship with the Role
entity:
We have established a Many-to-One relationship, assuming that in our system, one employee can have only one role. However, one role can be assigned to multiple employees. Additionally, we have added a column to the employees
table to avoid creating a new junction table. Great.
Let's retrieve all employees to check if everything is currently working correctly:
Now, we are interested in implementing standard CRUD operations for the Role
entity in the DAO and Service layers. I'll leave this task to you for the next chapter, as you have done this many times before, and I don't think it will be a problem for you.
Department Update
Currently, none of our employees have a department assigned. Let's fix that. For this, we'll write code that assigns a department to an employee entity based on their ID.
To achieve this, let's define a method setDepartmentById()
in the EmployeeDao
interface. This method will accept two identifiers: the employee's identifier and the department's identifier. The method should return the modified employee:
Now we need to implement this method in the EmployeeDaoImpl
class.
Here's the action plan for how we will implement it:
- Open a
session
; - Begin a
transaction
(since we will be making some changes to the database); - Retrieve the employee by ID from the parameters using the previously written
getById()
method; - Retrieve the department by ID from the parameters using the
getById()
method from theDepartmentService
interface; - Assign the retrieved department to the employee using the
setDepartment()
method; - Call the
merge()
method on thesession
object, passing theemployee
we want to update as a parameter; - Call
transaction.commit()
to save the changes to the database; - Handle errors and close the
session
as per usual.
The code will look like this:
As you can see, this doesn't look difficult at all; this is how update operations are implemented in the DAO layer. Now let's implement this method in the Service layer, after creating this method in the EmployeeService
interface.
The implementation of this method will look like this:
For testing purposes, let's assign a department
with id 1 to an employee
with id 1, and after calling the method, the employee object will look like this:
The department has been successfully added, and the employee
object has been updated in the database.
Method Overloading
Now let's move on to something more interesting. It won't always be convenient for us to assign a department by its ID; it would be much more convenient to directly assign a department as an object.
To implement this, we can overload the method:
We will do this in the service layer!
Let's proceed with the first overload, and the algorithm of our actions will look like this:
- Perform a null check, throwing a
NullPointerException
iftrue
; - Fetch all departments into a list to later check if the specified department exists in the database;
- If the department is not found in the database, throw a
NoSuchElementException
; - If the department is found in the database, use the
setDepartmentById
method after retrieving the department identifier withgetId()
.
The final implementation of such a method would look like this:
Let's test this method:
After testing such a method and assigning the Human Resources department to the second employee, the employee will look like this:
Note
It's worth mentioning that in order to overload the method, we need to overload it in the interface first and then implement it in the implementing class.
Great, now we can easily assign or update the department
for an Employee
object. I hope you've absorbed everything because, in the next chapter, you'll have to implement the same for the Role
entity.
Obrigado pelo seu feedback!