2
votes

I'm using PHP Codeigniter atm. I've read a couple posts that stresses the "Fat Model and Thin Controller" and that the model is supposed to handle all the business logic, have the methods that deal directly with database and controllers deal directly with user input. Following these rules, it seems necessary to pass the $_POST array data indirectly to model through controller. But sometimes it's much more straight forward and almost necessary to deal with the user data directly in the controller

Also CI's form_validation class doesn't let you set custom error messages in the form_validation.php in the config file. To do that we need to write call_back methods. But if we gonna write call_back methods for each field, the controller is going to get 'fat' and also why would I use the form_validation class in the first place.

Another thing is that often at times I find the need to generate content according to the database and user input and etc. But doing so in the controller seems to go against the "separation of logic and presentation". For example, CI has a form and table helper, pagination, etc... These are all presentation stuff. And writing these in the controller will make controllers fat again. So I guess I should maybe write controller methods for view generation or should I write a model or library to deal with presentation?

I'd appreciate some good advice and hints on the general MVC approach. Thank you.

1
Well, the thing is, that CodeIgniter has nothing really to do with MVC (aside from using it as marketing tool). As for "form validation", in proper MVC setup you should (and would) be able to separate the presentation layer from model layer. It shouldn't matter that the data comes from a html form. The validation rules ARE part of business rules. Which is why it should happen inside the model layer. In particular - inside domain objects.tereško

1 Answers

1
votes

You could take a look at how it is done in CakePHP, they attempt to stick closer to the MVC architecture.

But sometimes it's much more straight forward and almost necessary to deal with the user data directly in the controller

You almost never want to do this. Things are much cleaner when the controllers just call a bunch of model methods. This encourages code reuse because then you can easily refer to the same model method in another controller.

To do that we need to write call_back methods. But if we gonna write call_back methods for each field, the controller is going to get 'fat' and also why would I use the form_validation class in the first place.

For Form Validation, the model has a validate property with array of fields to validate and there is a general validates method on all models that checks the data being saved against the model's validate property. It can then 'invalidate' a single field in the data and pass this back to the view which displays the error on the field.

So I guess I should maybe write controller methods for view generation or should I write a model or library to deal with presentation?

Write a Helper class. The Helper classes are treated as shared code between the views rather than being part of the controllers.