Interaction between php model and controller

learn to use Tp5.1

when looking at other people"s code, I think a lot of operations about the database are written into the controller;

public function save()
{
    $data = input("post");
    $validate = $this->validate($data,"app\\common\\TestValidate");
    
    $result = (new UserModel)->save($data);
    
    if($result){
        return $this->success("");
    }else{
        return $this->success("");
    }
}

but some people say that it is not necessary to use the model, and the method of writing data can be written into model

but how to determine whether the write is successful or not when the controller is called in model?
and whether the data verification should be written in the controller or the model?

for example, the user registers the front end to submit-> the controller receives the request-> Model
the data verification in this is written to the controller or the model

there is no doubt if you write to the controller, but if you write to the model

how does false return an error message if validation fails in the model? Does it mean that an array is returned in the model ["status"= > 0 recording msgears = >" mobile phone number has been registered"];

then will the controller receive the status returned by the array returned by the model?

and by the way, how should the service layer and logic layer be used?

there are a lot of questions. I hope everyone will let me know. Thank you.

Mar.28,2021

1.MVC find out! Logic control is written in the controller and data processing is written in model.
2. The controller calls the method in model, and the success or failure of the method execution of model returns a Boolean value, and then the controller determines the result of the execution according to the Boolean value.
3. Answer 1


what you should see is a form of a lot of ubiquity, or using some kind of framework and then deviating from our original intention!
first of all, for the programming idea MVC, we have separated the front and rear ends, so we continue to separate the controller from the model processing on the back end, so our data processing should indeed be written in model, and the controller is only responsible for scheduling


if you fully follow MVC, the data processing must put model, and then controller is responsible for calling model and then performing logical processing according to the data returned by model. Model in TP can also be validate.

The

service layer is a hierarchical service, of model, separated together by logic, which is a separation of model, where service is responsible for providing the interface to controller, and logic helps controller process logic.
for example, for verification, model can only do additions, deletions, changes and queries, and logic calls model to make a judgment and the processing logic is returned to service.
is to reduce the coupling between methods


according to reason, it should be written in model, but now various AR encapsulation methods for database query are convenient for you to write directly, so simply write them directly in controller:

(new UserModel)->save($data);

do you need to encapsulate it in model?

public function saveUser(){
    self::save();
}

some people may think that it is convenient to modify after unified encapsulation, but now it is also very convenient to modify in batches in IDE, and this basically does not happen. Individuals feel unnecessary. Simple database interactions can be written directly in controller, while complex and reusable interactions need to be placed in model.

The most important thing in

MVC is M, that is, the model, controller only transfers. All places dealing with data or databases are generally done in model. Some frameworks subdivide the model layer into service layer and logic layer


.

I think the main question of the building should be this line:

how does false return an error message if validation fails in the model? Does it mean that an array is returned in the model ['status'= > 0 recording msgears = >' mobile phone number has been registered'];

if you put all the code that processes the data into the model, sometimes you have to return the data after passing, without the need to return an error message, it is really troublesome to make a judgment in the controller.

it is indeed a method to uniformly return data in the format of ['status'= > 0 msg/data' 1database info "= > msg/data].
but it is always a bit troublesome to write.

of course, the returned msg is usually string, and the returned data is usually array, so it can also be considered by judging the type of data returned. (but sometimes there are special cases)

therefore, it is more convenient to write directly to the controller.

if the logic of data processing is complex and may be used in other controllers, write it to the model.
if the logic is relatively simple, it is impossible to use it in other controllers, so it is more convenient to write to the controller.

if you want to pursue rigor, you must sacrifice "convenience"!
however, PHP is a language that pursues convenience.

Menu