use the one-to-many or many-to-one

2019-05-22 13:24发布

问题:

Two class:

Department Task

One department can have many tasks. One task can only belong to one department.

So use one-to-many or many-to-one?


one-to-many
class Department{
  private Set tasks;
}
class Task{
  ......
}
//
Department.hbm.xml
....
<set name="tasks">
    <key column="departId" />
    <one-to-many class="Task" />
</set>
.....

many-to-one

class Department{

}
class Task{
  Department depart;
}
//
Task.hbm.xml
....
<property name="depart">
    <many-to-one class="Department" />
</property>
.....

What's the difference?

BTW,what is the difference between use the set and list?

And example using list(xml configuration)?

回答1:

Your choices would depend on 2 things:

  1. What are various scenarios under which this relationships are used. For e.g. if you need to list your tasks by departments than One to Many is what you would need. It would also be easy for you to load them once since you are using Hibernate.

  2. If you update your tasks by department then you need the other relationship too.

However, remember this decisions have deep roots into your domain model and how you want to structure it. What are the usecases under which these entities are used. I would strongly recommend reading this SO thread and moreover watch this video by Eric Evans.

Hope that helps.



回答2:

A Task cannot exist without a Department I suppose, but a Department can exist without a Task associated with it. So the dependency is on the Task to attach itself to the Department, hence should be the owning side in the relationship. Many-to-One should be your choice here.



回答3:

Just by looking at the structure, I would choose many-to-one.
If a task has to be reassigned to another department, then only the task object needs to be altered, not the original department object.

From java collections, a Set does not allow duplicates, whereas a List might



回答4:

You should define a join table called DEPARTMENT_TASKS and have a ManyToMany relationship between them.