timdedrick timdedrick -4 years ago 87
PHP Question

Handling GET request variables

I tend to keep my controllers small to help follow the sequence of events and am considering using a model action and model mapper so that the controller action calls the model action to handle the business logic. I have considered passing a request object to the parent model action but I would like to handle URL parameters and session data in the controller to prime the business logic. An example:

indexAction(){
$getVar = $this->_request['getVar'];
$action = new Model_Action();
if(!empty($getVar)){
$action->doOneAction();
}else{
$action->doOtherAction();
}

switch($action->getResult()){
case 'wonderful':
$this->render('wonderfult_things');
break;
case 'terrible':
$this->render('terrible_errors');
break;
default:
$this->render('lorem ipsum');
}
}


So my question is should this logic exist in the controller? It seems if I handle this in a more elegant manner all my controllers look nearly the same with a couple calls to the model and render so what's the point? Example:

indexAction(){

$action = new Model_Action();
$result = $action->doThings();
switch($result){
case 'wonderful':
$this->render('wonderfult_things');
break;
case 'terrible':
$this->render('terrible_errors');
break;
default:
$this->render('lorem ipsum');
}
}

//in model:
doThings(){
$getVar = $this->_request['getVar'];
if(!empty($getVar)){
$this->doOneAction();
}else{
$this->doOtherAction();
}
}


Perhaps I'm splitting hairs here, but it seems to me the controller and requests have a closer relationship I just never seem to be using my controller to do anything other than calling the model to do something then render. Any opinions on this?

Update:

An example is requesting a list. One request returns the titles for a category, then the other request returns a specific list with a range of children using an additional api parameter. Within the context of the application it makes sense for these to share the same view though it's a bit more involved sharing graphical representations of data. I will decide how much knowledge of the two between the two fits by better defining my API. Perhaps only User aware API params might be used by the controller for contacting the model? Thanks.

Answer Source

Ideally your controller should only manage the interaction between the UI and your application. So no business logic should be placed in controller. If you're trying to follow a Domain Driven Design (https://en.wikipedia.org/wiki/Domain-driven_design), all your business logic should be enclosed in application/business services and in the model itself.

In your example, it seems that what doThings() does, is not something really related to business logic, but rather to how the user interacts with the application, since you're chosing what to do only on the basis of the request parameter getVar. If this is the case, then that condition should be placed into the controller.

Services and the model should not be aware of how the user placed the request. In principle, your application could interact with the user via other UI other than a web UI.

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download