这是一个创建于 2240 天前的主题，其中的信息可能已经有所发展或是发生改变。
- 对于 model 的 afterSave 方法使用有点疑问，请指教：
- 假设有 a,b,c 三个保存数据的业务逻辑，且有先后顺序，则伪代码书写方式：
- 第一种
a();
b();
c();
- 第二种
a.save()
a 里面有一个执行 b.save()的 afterSave()
b 里面有一个执行 c.save()的 afterSave()
- 如果仅仅是业务上的依赖关系，那么第二项种方式推荐使用吗？个人认为第二种方式没有第一种方式直接。如果考虑到共用代码，也可以把第一种方式直接封装下。如果第二种方式不推荐在这种场景下使用，那么其设计初衷是什么？
3 条回复 • 2019-09-10 09:14:54 +08:00
 |
1
ch3nz 2018-10-31 10:44:53 +08:00  1
aftersave 里面不要放业务逻辑,代码多了或者人不靠谱了，调试起来会很费劲。基本上用调用来发个消息啊更新个缓存啊之类的失败也没太大关系的那种逻辑。
既然三个方法是有顺序且相关联的，那就放到一个事务里面就好 ``` beginTransaction try a() b() c() commit catch rollback ``` |
 |
2
898601566 2018-10-31 11:10:55 +08:00
楼上说的对,多个数据表操作放在事务里面比较合适
|
 |
3
hbhe 2019-09-10 09:14:54 +08:00
这个问题很好，我也一直在思考，一般情况下，我会选第 2 种。
1. 如果 a.save()的时候，必然导致 b.save()，那么就说明这段逻辑关系是固定的，放在 afterSave()中可以被更多的地方复用。 2. 采用 2 时, 在 a.save()时，b,c 会依次 save()或者说依次向上冒泡，向上冒泡的过程要避免再次执行上级的 save()，以免形成递归震荡, 可使用 updateAttributes()来避免。冒泡一般是从底往上冒，什么是底？ 一对多时，多的那方的 model 是底，一对一时视业务而定。 3. 一层只管一层，如 a 只管 b, b 只管 c; 4. Model 负责逻辑中心; 而 afterSave()是中心中的中心，应高度重视。后半句个人之见。 |
Select Language