CodeIgniter Forums

Full Version: skinny controller or skinny model?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

El Forum

[eluser]solid9[/eluser]
Which is better

skinny controller & fat model?
or
fat controller & skinny model?

And why?

Thanks in advanced.

El Forum

[eluser]solid9[/eluser]
Currently I'm using fat controller & skinny model

In layman's word,
More codes in the controller and lesser codes in the model.

Yours? and why?

El Forum

[eluser]PhilTem[/eluser]
I tend to have a huge MY_Model but then every model itself is very very very thin. All the logic basically goes into the controller since this is, in my eyes, the dispatcher and what makes all the business logic.
Sometimes there's also need for a fat library if I need to "combine" multiple models that deal with the same part.

To quickly answer:
Fat controller - thin model.

El Forum

[eluser]WanWizard[/eluser]
Skinny controller, definately.

The controller should control the flow between request and output, it should not contain any business logic, only the logic required to control the flow and optionally to do any conversions needed to pass data from model to view.

El Forum

[eluser]solid9[/eluser]
Thanks for your input guys.

Well I guess this is what I'm thinking right now.
The Fat Controller & Skinny Model is best for intermediate CI programmers.
The skinny Controller & Fat Model is best for Advanced CI programmers.

Anyway this is my opinion as I saw more advanced CI programmer using the skinny controller & fat model.
Maybe in my next project I'll try the opposite method.
And to observe which is much more convenient to use.


El Forum

[eluser]PhilTem[/eluser]
As I stated above: My MY_Model is huge (around 3k SLOC) but every model extending it is very small (only around 50 SLOC).
Therefore my controllers tend to be a little bigger (even though MY_Controller is still the biggest with around 400 SLOC at the moment) since they grab data from the libraries, adjust the template and that stuff. Have a look at how "professionals" do it like in PyroCMS or Bonfire. They have rather big controllers, too.

And, just noticed, it also depends how you define fat controller. If you have many many methods in your controller but each method only has less than 10 LOC, is it still fat or not? If you only have two methods but these are around 100 LOC, is it fat or not?

Anyhow, I'd say: Do it the way your comfortable with, though I am not sure if your 'fat controller intermediate CI' comparison is right Wink You might offend people Big Grin

El Forum

[eluser]WanWizard[/eluser]
For me, "fat" has nothing to do with the number of lines of code. For me it means you have busines logic in there instead of in the model.

El Forum

[eluser]solid9[/eluser]
@philtem

Sorry I don't intend to offend people.
As I said also I'm currently using fat controller.

You have the point, just find where you are comfortable with.

El Forum

[eluser]solvo[/eluser]
For me personally, I like to use the MVCCS idea:

Model - gets data from your database and cache. Returns raw data to the service that will handle formatting it as needed.
View - renders output given to it by a component.
Controller - serves as gatekeeper for access to pages, defines pages as a series of modular components placed within a layout.
Component - builds a discrete, functional block of a page, takes in parameters from the controller, returns html from the view.
Service - contains the business logic for a certain feature set so that numerous components or controllers do not have to duplicate the same code and logic, cutting down on redundancy and headaches when something has to change.

I've built an open-source library on top of CodeIgniter so my projects are all already set up to rock and roll this way if anyone has any interest in trying this methodology - https://github.com/xjstratedgebx/CodeByrner.

I think at the end of the day, how you do things is a lot about personal preference. I tend to work on projects as part of a team that produces production sites that involve unit testing and a whole other department that does quality assurance to ensure that what will be pushed to our production environments are sound and perform well under load. Given what we do, we need a system that is modular so that we can partition work, but where business logic is not dispersed so 3 guys aren't writing different methods to check the same conditions or get the same data. I fully recognize that this isn't always the best solution for every project however.

Guess what I'm trying to say is this is how I like to do it, but it's not THE way to do, just A way to do it, as PhilTem said above.

El Forum

[eluser]cartalot[/eluser]
My newbie perspective

start with a fat controller, and then as you test and develop -- push functions and code to the model when you know they are working --
to then make the controller skinnier and more elegant.

that way the controller is your main development area/ sandbox -- you arent trying to debug code in both the model and controller. and then the more code you push to the model, the easier it is is to see the overall logic going on in the controller.

another suggestion is to standardize the sections of your model, and try to follow or label them the same way.
like validation, insert, update, delete etc.