PHP 框架 Model 层是否应该统一 DB 和 Cache
后来发现它统一了 db 和 cache 的方法为 get/set，很喜欢这样的方式，这样在 Model 出口之前，对于 Action 来讲底层数据来源就变得透明了，可以直接配置文件开启缓存，而 Action 并不需要关心这些。
但是看到 Model 的抽象基类在调用 db 和 cache 的时候，貌似统一了方法名也没带来什么好处啊？
db
get/set/...
cache
get/set/...
model
get
# cache enable
db_cache_get
cache_get OR db_get&cache_set&cache_get
# cache disable
db_get
set
# cache enable
db_cache_set
cache_set&db_set
# cache disable
db_set
cache_get 和 db_get 中虽然都是获得相应的 instance 然后一致的 get，这个名字统一貌似也没带来什么好处嘛...
1、既然要统一，为啥不统一 implements 同一个 interface 或者 extends 同一个 abstract？即使不统一，db 一个 interface，cache 一个 interface，Model 中的 db_get 和 cache_get 还是照样各自实现各自啊，看到 db/cache/Model 一遍遍的 get/set 实在是... 而且 Model 中各种各样的 get/set 也感觉有点“野”。前辈们在实现的时候如果有过这样的场景，是怎么实现的呢？
2、是不是应该在 Model 中统一 db 和 cache 操作呢，这样对于 Action 来说不是更方便透明吗？一个配置文件就可以开关缓存，但是发现 CI 和 Yii 的 cache 操作例子中，很多 cache 操作直接穿透到了 Action 中。如果需要统一，那是在 db/cache 和 Model 之间加一层，还是直接在 Model 基类中实现合适呢？
回复内容：
之前看到 xiuno 号称高承载，然后看了一下数据库是 MyISAM 引擎（这个就不提了），一直困扰我的 LIMIT 效率问题发现它的实现也只是简单的在 thread.class.php 中判断超过多少页之后倒序取数据。
后来发现它统一了 db 和 cache 的方法为 get/set，很喜欢这样的方式，这样在 Model 出口之前，对于 Action 来讲底层数据来源就变得透明了，可以直接配置文件开启缓存，而 Action 并不需要关心这些。
但是看到 Model 的抽象基类在调用 db 和 cache 的时候，貌似统一了方法名也没带来什么好处啊？
db
get/set/...
cache
get/set/...
model
get
# cache enable
db_cache_get
cache_get OR db_get&cache_set&cache_get
# cache disable
db_get
set
# cache enable
db_cache_set
cache_set&db_set
# cache disable
db_set
cache_get 和 db_get 中虽然都是获得相应的 instance 然后一致的 get，这个名字统一貌似也没带来什么好处嘛...
1、既然要统一，为啥不统一 implements 同一个 interface 或者 extends 同一个 abstract？即使不统一，db 一个 interface，cache 一个 interface，Model 中的 db_get 和 cache_get 还是照样各自实现各自啊，看到 db/cache/Model 一遍遍的 get/set 实在是... 而且 Model 中各种各样的 get/set 也感觉有点“野”。前辈们在实现的时候如果有过这样的场景，是怎么实现的呢？
2、是不是应该在 Model 中统一 db 和 cache 操作呢，这样对于 Action 来说不是更方便透明吗？一个配置文件就可以开关缓存，但是发现 CI 和 Yii 的 cache 操作例子中，很多 cache 操作直接穿透到了 Action 中。如果需要统一，那是在 db/cache 和 Model 之间加一层，还是直接在 Model 基类中实现合适呢？
市面上的框架，为了增加“傻瓜化”操作，
所以会集成很多这样的功能，你只需要稍微改下配置，就能切换，很方便，
但是本人很不喜欢这样的操作，
1.封装太多造成黑盒效应，搞得其他人稀里糊涂的。
2.统一的方法名，不利于发挥各自的特性，比如memcache和redis，你如果仅用set和get也就失去redis的意义了。
3.不适合大数据量的项目，对于大数据量的项目，后期会把各个模块拿出去成为独立的服务。如果你把ceche和数据库弄到一起，后期重构需要花些力气。
本人喜欢用模块，模块间彼此独立，互不干扰。比如读取数据，先去缓存模块，缓存模块没有读到数据，再去数据模块，然后反馈给缓存模块。
而在缓存模块，根据配置，去相应的file，或mc，或redis，这三者也是彼此独立的。互不干扰。
这也是符合高内聚低耦合概念的。
当然，市面上大多数的框架会给你封装的很好，因为他是为了尽可能减少用户操作，让用户用最简单的修改，带来最大的效果。
过度的封装可能让你一时爽，当要改变时要命，过度封装必然会耦合高。
DB的效率没有cache高，统一接口带来的好处远没有带来的坏处多。
倒是不同类型的cache，比如redis、memcache、文件缓存之类的可以统一接口。