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:

1. Delete the position column;
2. Create the Role table;
3. Create a column in the Employees table that will be a foreign key for Role.

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:

1. Open a session;
2. Begin a transaction (since we will be making some changes to the database);
3. Retrieve the employee by ID from the parameters using the previously written getById() method;
4. Retrieve the department by ID from the parameters using the getById() method from the DepartmentService interface;
5. Assign the retrieved department to the employee using the setDepartment() method;
6. Call the merge() method on the session object, passing the employee we want to update as a parameter;
7. Call transaction.commit() to save the changes to the database;
8. 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:

1. Perform a null check, throwing a NullPointerException if true;
2. Fetch all departments into a list to later check if the specified department exists in the database;
3. If the department is not found in the database, throw a NoSuchElementException;
4. If the department is found in the database, use the setDepartmentById method after retrieving the department identifier with getId().

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.