域建模的又一困惑!

订单Order与帐户Account;类别Category与产品Products这几个类。
我得开始想法,Order需要知道Account的知识,而Account也需要查询对应的Order列表;这样二者可以建立双向一对多的关联。Category与Products二者的关系也是一样,双向一对多关联。
但是我发现,Order与Account的关系不似Product和Category之间关系那么紧密。Category与Product似乎是一个比较严格的一对多的双向关联,而Order和Account之间又隐隐的存在这种一对多的双向关联,可是有感觉有些不妥。
二者存在以下不同:
对于Category有更新的操作,可以先取出现有的products列表,然后update这个products的列表。进行更新;
而对于Order却没有类似的操作,需求上只有下定单,查许某帐户的曾经的下单,根据订单查询帐户信息的需求,似乎Order和Account之间的关系比较的淡化,这种情况如何建立二者的关系?

Category与Product是MANY-TO-MANY的关联, 级联水平应该是save-update, 这种关联一般都存在O/R MISMATACH的问题(需要LINK TABLE).

另外,这种问题通常都存在一个隐含关联对象,他不易被发现.但他可以将原本多对多的关联转换成两个unidirectional 一对多关联.举个例子:

company (1) -- (*) employment (*) -- (1)employee

不大明白:多对多关联为什么级联为save-update?delete不可以么?还有:mismatch的问题似乎在 o/r中普遍存在,即使一对多,一对一关联也有mismatch哦,只不过mismatch的类型和方式不同^_^。

我上边的问题,可以归结为:
Order和Account这两个模型,是否应该Account中有多个Order?即


class Account{
private name;
......
private Set orders; //一对多个Order?
......
}

让您来做这个建模的话,怎样进行?(需求上有根据用户帐号查询订单列表的需求)

"不大明白:多对多关联为什么级联为save-update?delete不可以么?还有:mismatch的问题似乎在 o/r中普遍存在,即使一对多,一对一关联也有mismatch哦,只不过mismatch的类型和方式不同^_^。"

因为两端的对象或实体都有自己的生命周期,删除任何一端另一端都不应被级联删除。

“我上边的问题,可以归结为:
Order和Account这两个模型,是否应该Account中有多个Order?即

class Account{ private name; ...... private Set orders; //一对多个Order? ......}

让您来做这个建模的话,怎样进行?(需求上有根据用户帐号查询订单列表的需求)”

这个模型是最简单的模型,采用合成模式,确切地就是父子关系建模。

account负责order的生命周期,当然你也可以在之间使用双向关联。即,order端many-to-one

class Order{
Account account;
}

“因为两端的对象或实体都有自己的生命周期,删除任何一端另一端都不应被级联删除。”
我指的是关联对象的级联删除。级联的对象生命期是由双方来控制的吧?

既然关联双方都有自己的生命期,那么save-update怎么就可以级连呢,难道我save一方可以导致另一方的save么,我想你说的save-update也是关联对象中间的save-update级连吧?这不是如同删除一样么?


Kidwish:可否考虑深入一些?你的想法是最浅层次的考虑。当然从直观上看是个一对多的关联,但是二者并非严格的父子关系。

请稍加分析,看看我说的是否有道理:
父子关系是这样:我可以向Parent中加入一个子。父子关系有着样的关系:新增一个子,相当于向父亲的所有子类表中加入一个子对象。
但是下单不是这样,并非向某个帐户中加入一个订单。也就是说,二者的关系从逻辑上讲并非那种一个帐户下包含多个订单的关系。下单操作能说是向一个帐户订单列表中加入一个订单么?显然逻辑上说不通的。
其实我也有些说不清出,就是感觉上,觉得二者并非这种严格的父子关系。

"Kidwish:可否考虑深入一些?你的想法是最浅层次的考虑。当然从直观上看是个一对多的关联,但是二者并非严格的父子关系。
请稍加分析,看看我说的是否有道理:
父子关系是这样:我可以向Parent中加入一个子。父子关系有着样的关系:新增一个子,相当于向父亲的所有子类表中加入一个子对象。
但是下单不是这样,并非向某个帐户中加入一个订单。也就是说,二者的关系从逻辑上讲并非那种一个帐户下包含多个订单的关系。下单操作能说是向一个帐户订单列表中加入一个订单么?显然逻辑上说不通的。
其实我也有些说不清出,就是感觉上,觉得二者并非这种严格的父子关系。"

我是说账号负责订单的生命周期(删除账号要删除对应订单列表),从关联上说可以是单向一对多或双向一对多。从模式上来分析就是合成模式。

父子关系是我理解错了,见笑了!

“因为两端的对象或实体都有自己的生命周期,删除任何一端另一端都不应被级联删除。我指的是关联对象的级联删除。级联的对象生命期是由双方来控制的吧?既然关联双方都有自己的生命期,那么save-update怎么就可以级连呢,难道我save一方可以导致另一方的save么,我想你说的save-update也是关联对象中间的save-update级连吧?这不是如同删除一样么?”

我所说的save-update是对LINK-TABLE的,而不是对有生命周期的实体(对象).原因很简单:删除CATEGROY,不会把PRODUCT都删除,只是把LINK-TABLE记录删掉,更新也是如此.那么,级联删除根本就没有意义!

还有多对多两端的对象都是由自己来管理生命周期的.当然也可以指定一端,这样可以提高SQL的效率(HIBERNATE就是通过inverse来这样做的)



呵呵,那就是误会咯,我得理解是一样的,
update,save,delete都是针对“级连中间对象”,也就是你所说的中间表。