MVC - Controllers

hargi

hargi

hargi

Associate
Joined
19 Jul 2006
Posts
1,847
Looking for others thoughts on this.

I know it should be Fat Model and thin controllers.

However when I have worked in RoR or Laravel and even in my old job with there own framework. I have always had my crud functions in my controller.

So eg.

PHP: 
Class page extends BaseController
{
 public function get(){
if(isset($id)){
// do some stuff
  }
 }

public function post(){
//do some stuff
}

}

or
PHP: 
class page extends CaseController{
public function show(){}
public function edit(){}
public function update(){}
public function list(){}
public function delete()[]
}


however people are advising me to use one controller per action which seams to be a bit overkill and causes duplication.

They are claiming its more SOLID

however in my mind a controller should kind of represent an object am i correct in this thinking or wrong?
 
One controller per action seems... well, ludicrous. It may well be more SOLID (from a literal single responsibility perspective) but it's completely impractical and not how MVC is designed to work.
 
The hell, in a large system there would be thousands of controllers! That cant possibly work.

Our controllers are very light, generally a controller represents the entity, so Client controller, Job controller. All the controller does is call an interface/logic that is elsewhere and returns the appropriate response.

Other than a little bit of security there is no logic at all in our controllers.
 
I think the controller should have a service injected into it, and then you invoke methods on that service from the controller, passing in data objects. That way you keep the controller thin.
 
That's one way to do it, but the problem with the service pattern is that you have to be careful that the services themselves don't turn in to God classes.
 
You must log in or register to reply here.
Back
Top Bottom