I use Spring MVC and a regular JDBC.
I've just learned that I should separate business process into layers which are presentation layer, controller layer, service layer, and repository/DAO layer. Now suppose that I have an Entity called Person that can have multiple Jobs. Job itself is another entity which have its own properties. From what I gathered, the repository layer only manages one entity. Now I have one entity that contains another entity. Where do I "join" them? The service layer?
Suppose I want to get a person whose job isn't known yet (lazy loading). But the system might ask what the job of that particular person is later on. What is the role of each layer in this case?
Please let me know if I need to add any detail into this question.
From what I could gather from the problem statement:-
- Person - can exists without job. Can have zero or more Job(s).
- Job - Can exist independent of Person(s) performing it.
A cleaner way would be to have a entity (and thus its table) that encapsulate this mapping:-
class Employment{
private Person person;
private Job job;
}
Now you can query from both ends. Like:-
- SELECT FROM EMPLOYMENT WHERE PERSON.ID=xyz
This might give 0 or more rows.
Each row will have information of mapped Job too.
So in this case you will have your service/repository something like:-
interface EmployementRepository{
// CRUD methods on Employement.
}
It sounds like your dealing with a many to many relationship. If multiple people can have the same job you will need to create a junction table.
DATA Model
CREATE TABLE PERSON(PERSON_ID, OTHER_FIELDS);
CREATE TABLE JOB(JOB_ID, OTHER_FIELDS);
CREATE TABLE PERSON_JOB(PERSON_JOB_ID, PERSON_ID, JOB_ID, OTHER_FIELDS);
Entities
class Person{
List<Job> jobs = new ArrayList<Job>();
}
class Job{
List<Person> workers = new ArrayList<Person>();
}
In the repository/dao layer, you will need to create the logic to fill these associations between the two entities using the junction table.
In the typical OOP the relationship between objects are made by creating an association. If the association between a Job and Person is many-to-one. Then you should add a property of a Person to the Job. From the other hand the association between Person and Job is one-to-many, so you could add a set of Jobs to the Person. You can map this association for lazy loading if you don't want to load all associated jobs of the person. This is used by default in ORM and JPA.
class Person {
Set<Job> jobs;
}
class Job {
Person person;
}
Each layer used to separate and decouple the logic used to handle the same or different objects.
On the other hand the objects used to map your object model could be different on each layer and you have to transform data when you need to update the model. It depends on implementation of the persistence framework used for the persistence layer. Having a service layer you can abstract from the persistence layer implementation, and if you lately change the persistence framework the business logic that is encapsulated in the service layer wouldn't change. The presentation layer might also contain its own objects known as a view objects used to handle different aspects of the presentation layer. The logic of creating, manipulating, and presenting these objects belongs to a presentation layer which is obviously implemented by the presentation framework.
