精益开发：更富表现力的Model层和重量级数据获取的应对方案.pdfVIP

精益开发：更富表现⼒的Model层和重量级数据获取的应对⽅案 我们能够有意识地推断我们想要在哪⼀条想法的溪流中遨游，然⽽此后与那些想法的 触会潜在地塑造我们的习惯和信仰。 -- 《智慧社会》 1.27.1 写在前⾯的话 此篇章有点长，但我认为是值得⼀读的。因为这⾥我将逐步讲述如何在已有的基础上 演变扩展出更⾼层次的代码结构和系统架构，⽽不致于因⽬前频繁的需求变更⽽导致 代码凌乱不堪。更为重要的是，你将能从中发现，如何在⼀个框架中持续演变，最终 体验浮现式设计的乐趣。如果你的项⽬亦能如此，我相信你会找到编程如同搭建积⽊ 般轻便明了的感觉。 1.27.2 更富表现⼒的Model层 ⼜不尽相同，主要区别在于领域业务数据的处理。⽽数据的来源则更为⼴泛，可能 是来⾃数据库，可能来⾃第三⽅平台 ⼜，可能存放于内存。所以，PhalApi这⾥的 Model层，则是 ⼴义 的数据源层 ，⽤于获取原始的业务数据，⽽不管来⾃何⽅，何 种存储媒介。这也是为什么我们没有将Model层打造成活动纪录或者数据映射器的原 因。当然，如果你确实需要，也可以⾃⾏调整。 如果数据来源于数据库，我们则需要考虑到数据库服务器的感受，保证不会有过载的 请求⽽导致它罢⼯。对此，我们可以结合缓存来进⾏性能优化。 如，⼀般地： // 版本1：简单的获取 $model = new Model_User(); $rs = $model-getByUserId($userId); 这种是没有缓存的情况，当发现有性能问题并且可以通过缓存来解决时，我们可以在 调⽤时简单引⼊缓存： // 版本2：使⽤单点缓存/多级缓存 (应该移⾄Model层中) $key = user aseinfo_ . $userId; $rs = DI()-cache-get($key); if ($rs === NULL) { $rs = $model-getByUserId($userId); DI()-cache-set($key, $rs, 600); } 但不建议在领域Domain层中引⼊缓存，因为会导致混淆和不便进⾏测试。更好是将缓 存的处理移⾄Model ，保持数据获取的透明性： class Model_User extends PhalApi_Model_NotORM { pu lic function getByUserIdWithCache($userId) { $key = user aseinfo_ . $userId; $rs = DI()-cache-get($key); if ($rs === NULL) { $rs = $this-getByUserId($userId); DI()-cache-set($key, $rs, 600); } return $rs; } 对应地，外部的调⽤调整成： // 版本2：使⽤单点缓存/多级缓存 (应该移⾄Model层中) $model = new Model_User(); $rs = $model-getByUserIdWithCache($userId); ⾄此，Model层对于上层如Domain来说，负责获取源数据，⽽不管此数据来⾃于数据 库，还是远程 ⼜，抑或是缓存包装下的数据。这正是我们使⽤数组在Model层和 Domain层通讯的原因，因为数组更加通⽤，不需要额外添加实体。 1.27.3 重量级数据获取的应对⽅案 纵使更富表现⼒的Model很好地封装了源数据的获取，但是仍然会遇到⼀些尴尬的问 题。特别地，当我们⼤量地进⾏缓存读取判断时，会出现很多重复的代码，这样既不 雅观也难以管理，甚⾄会出现⼀些简单的⼈为编写错误⽽导致的BUG 。另外，当我们 需要进⾏预览、调试或测试时，我们是不希望看到缓存的，即我们能够⼿⼯指定是否 需要缓存。 这⾥再稍微简单回顾总结⼀下我们现在的问题：我们希望通过缓存策略来优化Model 层的源数据获取，特别当源数据获取的成本⾮常⼤时。但我们又希望我们可以轻易控 制何时需要缓存，何时不需要，并且希望原有的代码能在OCP的原则下不需要修改， 但又能很好地传