-->

避免循环依赖(Avoid Circular Dependency)

2019-08-17 02:20发布

我正在开发一个旅游管理应用程序。 在问题的设计是一样的东西如下:

在参观每个人被指定为旅行者。 每个旅行者具有Passport。 现在,旅行者可以是MainMember或亚段,要看他是否是家庭的头。 一个MainMember决定的东西一样TourPackage,为他的家庭旅行总金额等。亚段依赖于在旅行中的MainMember。 所以,如果一个MainMember被删除,它的所有子成员都被删除。

因此,旅客有一个护照。 (一对一的关系)一个旅行者可以是一个MainMember或亚段。 (一到零/一个旅行者-MainMember和旅行者-亚段之间)甲MainMember可以具有若干子成员。 (一到多)甲亚段仅具有一个MainMembers。 (多到一个)

我现在的ERD的东西如下。

正如你所看到的,三个表 - 旅行者,MainMember和亚段 - 已经形成了循环依赖。 我不知道这是否会伤害我的应用程序,虽然。 如果我删除一个旅行者谁是MainMember,然后1.旅行者一条记录被删除。 2.其相关MainMember记录被删除。 3.依赖MainMember的亚段记录被删除。 4.子成员的旅行者记录被删除。

虽然它似乎并不成为一个问题,作为一个旅行者,MainMember删除永远只删除旅行者 - 子构件(S)。 不过,我对此有一种不好的预感。

任何人都可以引导我到一个更好的设计?

UPDATE -

在等待答复,我想出了另一种设计,基于@ Daveo的答复。 基本上,旅行者包含自参照外键。 它将使亚段记录被用来识别他们的父母。

这里是ERD了点。

现在,因为没有我以前的设计循环依赖,如指向的@Branko的问题,我想知道哪些设计是更好?

此外,该设计会更好,通过Hibernate实现? 我认为,虽然通过Hibernate实现第二种方法可能导致的复杂性。

我还希望关于实现模式(继承在Hibernate中的实体,等等),你更喜欢设计一些指点。

Answer 1:

正如你所看到的,三个表 - 旅行者,MainMember和亚段 - 已经形成了循环依赖。

没有,这不是一个循环依赖-无“节点”在此图可以通过在其适当的方向1下图“边缘”达到本身。 将它更准确地描述为“合并”或甚至(原)“菱形”依赖性。

不,它不会伤害你的应用程序。 2

您正在有效实施的继承 (又名类,子类,子类型,概括层次等),使用“每个类在单独的表”的方式。 这种方法是干净的,但不能保证开箱存在3和排他性4。 有一些方法可以修改它它确实是这样,有继承,可以实现其他策略,但他们有自己的优点和缺点 。

在我看来,你的模型是蛮好的,你正在尝试什么来实现和执行应用程序级别的存在/排他性可能是不幸中之大幸比痛苦的努力在数据库级别来执行它的利弊。


1“方向”是从参考到引用表。 Traveller不引用MainMember也不SubMember ,因此打破了循环。

2,除非你是一个数据库管理系统(如MS SQL Server)的,不这样“合并”的依赖关系(在这种情况下,你需要实现CASCADE通过触发器DELETE)支持引用操作。

3 Traveller不能单独存在(不能是“抽象”),它必须是MainMemberSubMember

4 Traveller不能同时MainMemberSubMember



Answer 2:

我只会在数据库中的两个表。

旅行者和密码

旅行者将有PARENT_ID场,这将链接到旅行者表,将存储在主/头的旅行者是谁。 还存储共同要么主/副成员字段在此表等接触数

然后使用继承和ORM创建您的实际应用中两个不同的类。 MainMember和亚段MainMember将是旅客所有行PARENT_ID为空亚段将是旅客所有行PARENT_ID不为空



文章来源: Avoid Circular Dependency