使用一对多或多对一
第二类：
部门任务
一个部门可以有多个任务。一项任务只能属于一个部门。
那么使用一对多还是多对一呢？
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>
.....
多对一
class Department{
}
class Task{
Department depart;
}
//
Task.hbm.xml
....
<property name="depart">
<many-to-one class="Department" />
</property>
.....
有什么区别？
顺便说一句，使用集合和列表有什么区别？
以及使用列表（xml 配置）的示例？
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)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为，如果没有部门，任务就不可能存在，但部门可以在没有与其关联的任务的情况下存在。因此，依赖关系是任务将其自身附加到部门，因此应该是关系中的拥有方。多对一应该是您的选择。
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.
您的选择取决于两件事：
使用此关系的各种场景是什么。例如，如果您需要按部门列出任务，那么您需要的是一对多。由于您使用的是 Hibernate，因此您也可以轻松加载它们一次。
如果您按部门更新任务，则还需要其他关系。
但是，请记住，此决策深深植根于您的领域模型以及您想要如何构建它。使用这些实体的用例是什么？我强烈建议阅读此SO线程以及观看 Eric Evans 的这段视频。
希望有帮助。
Your choices would depend on 2 things:
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.
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.
仅从结构来看，我会选择多对一。
如果需要将任务重新分配给另一个部门，则只需更改任务对象，而不需要更改原始部门对象。
在 Java 集合中，Set 不允许重复，而 List 可能允许重复
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
您应该定义一个名为 DEPARTMENT_TASKS 的联接表，并在它们之间建立多对多关系。
You should define a join table called DEPARTMENT_TASKS and have a ManyToMany relationship between them.