今天看《重构》一书说到“双向关联”和“单向关联”的转换。
比如`Customer`和`Order`之间的关系,很多时候我们需要根据Customer来对相关的orders做操作(增删查改),很直接的做法是在Customer里直接添加一个字段来保存一个list或者set,这就形成一个单向关联的关系了。之后如果又需要根据Order来获取对应的customer的话,一般你们会怎么选择?在Order里面增加一个字段来保存?还是以性能为代价,设置一个getCustomer()函数来遍历所有的customers并返回符合要求的customer?
这类问题我之前第一次独自做web后台模型层时自己把自己绕晕了,因为用了双向关联,而且字段都存了ID,没有用SQL的外键(不太希望数据库帮自己做一些自己还不是很了解的事情),最终导致各种不一致,比如删除一个customer没有删除对应的orders等低级问题,而且最后解决这些问题也是很痛苦的过程,这或许也是我想看《重构》这类书的原因之一,但还是觉得自己的变成经验还是太少了,只一两个做过小型网站,所以感觉自己对这一块的思想还不是很清晰,请大家多多指教~
比如`Customer`和`Order`之间的关系,很多时候我们需要根据Customer来对相关的orders做操作(增删查改),很直接的做法是在Customer里直接添加一个字段来保存一个list或者set,这就形成一个单向关联的关系了。之后如果又需要根据Order来获取对应的customer的话,一般你们会怎么选择?在Order里面增加一个字段来保存?还是以性能为代价,设置一个getCustomer()函数来遍历所有的customers并返回符合要求的customer?
这类问题我之前第一次独自做web后台模型层时自己把自己绕晕了,因为用了双向关联,而且字段都存了ID,没有用SQL的外键(不太希望数据库帮自己做一些自己还不是很了解的事情),最终导致各种不一致,比如删除一个customer没有删除对应的orders等低级问题,而且最后解决这些问题也是很痛苦的过程,这或许也是我想看《重构》这类书的原因之一,但还是觉得自己的变成经验还是太少了,只一两个做过小型网站,所以感觉自己对这一块的思想还不是很清晰,请大家多多指教~


