PHP aggregation coupling ??? This is a common model interface: PHPcodeinterfaceAPI {publicfunctionmain (); publicfunctionparams ($ value) ;}then, the general model class inherits it: PHPcodeclasst PHP aggregate coupling ???
This is a common model interface:
PHP code
interface API{ public function main(); public function params($value);}
Then, the general model class inherits it:
PHP code
class test implements API { public function main(){ echo 'hello world!';} public function params($value){ var_dump($value);}}
The front-end controller parses the URL and instantiates the model class. it calls the interface to transmit model data:
PHP code
class Control{private function __construct(){ self::Router(); $obj = new self::$Model(); self::_Interface($obj);}public static _Interface(API $obj){ $obj -> main(); $obj -> params();}}
This is my simple coupling structure. However, this is only the coupling between the controller and the model class, and it is a common class. if it is a special class, you must use special interfaces and controllers, but this is not the case. the problem is that I want to allow interactions between models through interfaces (data coupling ?), But after thinking a lot, there is no practical solution. what should I do with this interface ???
For example, if I need to call a database-class function, it is generally called directly:
$ Db = db: main ();
# Db-> Query (***********************);
However, this does not conform to the concept of low coupling. I only need to change the Query (); the method is finished. what can I do to pull data ??
Or, you can give a data-coupled instance, and slowly research and calculate it ....
Thank you!
(Note: I know, some people may say that the above code is not perfect. what? Indeed, I have integrated some of the front-end controllers, but this is not the focus of my discussion today. if it causes visual inconvenience, please forgive me)
------ Solution --------------------
To be honest, you have no idea what you are going to do...
However, if the data layer needs to interact with each other, it should be done through the control layer. Otherwise, what should the control layer do? Because only the control layer knows the specific business logic relationship between the data, and the model should only care about its own one-acre, three-sub-location, all those beyond this range should be handed over to the upper layer for processing, this reduces coupling!
In addition, the $ db-> query problem can be converted
$ Db-> select ()-> where ()-> order ()-> limit ()
There are two methods:
1 and then Abstract
$ Db: fetch ($ where, $ order, $ limit ){
Return $ db-> select ('*')-> where ($ where)-> order ()-> limit ();
}
When calling
$ Db = db: main ();
$ Db-> fetch ($ where, $ order, $ limit );
2. you can encapsulate an underlying model base class.
Basemodel: fetch ($ where, $ order, $ limit ){
$ Db = db: main ();
Return $ db-> select ('*')-> where ($ where)-> order ()-> limit ();
}
Model basics
Class test extends basemodel implements API {
Function dothing (){
Parent: fetch ($ where, $ order, $ limit );
}
}
I don't understand the relationship between this and data coupling. this is just the encapsulation of calling db!
------ Solution --------------------
The second floor is justified. I personally think that the method to reduce coupling is that the display layer is only responsible for display, and the logic processing is handed over to the business logic layer. The data access layer only processes data, do it!
Concerning the database class, I suggest you check the uchome database class. I think his class is well written, which is similar to that on the second floor!
------ Solution --------------------
This is the base class of the controller. Not all controllers can follow the standard execution data provided by the base class?
------ Solution --------------------
I thought you should have been put into a misunderstanding by various nouns.
You actually want to transmit a certain information between each function module.
In fact, this is an easy-to-implement mechanism, that is, event-driven or message-driven widely used in operating systems.
A module broadcasts its own requirements. modules that can meet this requirement return the required data.
