Should the Model layer of the PHP framework unify DB and Cache?

Previously, I saw xiuno claim to be high-load, and then I checked that the database is the MyISAM engine (this is not mentioned). I 've been troubled by the LIMIT efficiency problem and found that its implementation is just simple in thread. class. in php, data is retrieved in reverse order after the number of pages is exceeded. Later I found it unified... previously, I saw xiuno claim to be high-load, and then I checked that the database is the MyISAM engine (this is not mentioned). I 've been troubled by the LIMIT efficiency problem and found that its implementation is just simple in thread. class. in php, data is retrieved in reverse order after the number of pages is exceeded.

Later, it was found that the db and cache methods were unified as get/set, and they liked this method very much. Before the Model was exported, the underlying data source of the Action became transparent, you can directly configure the file to enable the cache, and Action does not need to care about this.

But when we see that the abstract base class of the Model calls the db and cache, it seems that the method name is unified, which does not bring any benefit?

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_getset    # cache enable    db_cache_set        cache_set&db_set    # cache disable    db_set

Although cache_get and db_get both obtain the corresponding instance and get the same, it does not seem to bring any benefit if the name is unified...

1. Why not unify implements with the same interface or extends with the same abstract? Even if they are not uniform, the database has an interface, and the cache has an interface. db_get and cache_get in the Model still implement their respective implementations. We can see that the get/set in the db/cache/Model is actually... in addition, various get/set methods in the Model also feel a bit "wild ". How can we implement this scenario when our predecessors implement it?

2. Should I unify db and cache operations in the Model? Isn't it more convenient and transparent for Action? A configuration file can switch on and off the cache. However, in the cache operation examples of CI and Yii, many cache operations directly penetrate into the Action. If uniformity is required, should I add a layer between db/cache and Model, or should I directly implement it in the Model base class?

Reply content:

Previously, I saw xiuno claim to be high-load, and then I checked that the database is the MyISAM engine (this is not mentioned). I 've been troubled by the LIMIT efficiency problem and found that its implementation is just simple in thread. class. in php, data is retrieved in reverse order after the number of pages is exceeded.

Later, it was found that the db and cache methods were unified as get/set, and they liked this method very much. Before the Model was exported, the underlying data source of the Action became transparent, you can directly configure the file to enable the cache, and Action does not need to care about this.

But when we see that the abstract base class of the Model calls the db and cache, it seems that the method name is unified, which does not bring any benefit?

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_getset    # cache enable    db_cache_set        cache_set&db_set    # cache disable    db_set

Although cache_get and db_get both obtain the corresponding instance and get the same, it does not seem to bring any benefit if the name is unified...

1. Why not unify implements with the same interface or extends with the same abstract? Even if they are not uniform, the database has an interface, and the cache has an interface. db_get and cache_get in the Model still implement their respective implementations. We can see that the get/set in the db/cache/Model is actually... in addition, various get/set methods in the Model also feel a bit "wild ". How can we implement this scenario when our predecessors implement it?

2. Should I unify db and cache operations in the Model? Isn't it more convenient and transparent for Action? A configuration file can switch on and off the cache. However, in the cache operation examples of CI and Yii, many cache operations directly penetrate into the Action. If uniformity is required, should I add a layer between db/cache and Model, or should I directly implement it in the Model base class?

The frameworks on the market, in order to increase the "silly" operation,
Therefore, many such functions will be integrated. You only need to change the configuration slightly to switch over, which is very convenient,
However, I do not like this operation very much,
1. Too many packages cause the Black Box effect, which is confusing to others.
2. Uniform method names are not conducive to their respective features, such as memcache and redis. If you only use set and get, it will lose the meaning of redis.
3. It is not suitable for projects with large data volumes. For projects with large data volumes, various modules will be taken out to become independent services in the future. If you get ceche and the database together, it will take some effort to rebuild later.

I like to use modules, which are independent of each other and do not interfere with each other. For example, to read data, first go to the cache module, the cache module does not read data, then go to the data module, and then feedback to the cache module.
In the cache module, the corresponding file, mc, or redis are also independent of each other according to the configuration. Do not interfere with each other.
This is also in line with the concept of High Cohesion and low coupling.

Of course, most of the frameworks on the market will encapsulate you well, because they are designed to reduce user operations as much as possible, so that users can use the simplest modifications to achieve the maximum effect.

Excessive encapsulation may make you feel better. If you want to change, excessive encapsulation will inevitably lead to high coupling.

The efficiency of the database is not as high as that of the cache, and the benefits of the unified interface are far from the disadvantages.
Different types of cache, such as redis, memcache, and file cache, can provide unified interfaces.