Welcome Guest, Not a member yet? Register   Sign In
I'm at a standstill....need help with controllers (theory)
#1

[eluser]jleequeen[/eluser]
I feel like I'm beating a dead horse but I'm stuck so here goes. I've asked questions about controllers in these forums before and while I get good suggestions, I still am confused on the subject. I'm very comfortable with models and views. To me those are easy. But controllers still mystify me, because there really is no best practice to creating them.

On one hand, it seems much easier to design your controllers with a specific view in mind. One controller per view. That seems right, but only because I come from a spaghetti code background where the controller was nothing more than a snippet at the top of the view file. What it did was allow me to keep the controller very small and very focused.

On the other hand, I could have a "user" controller that does many things. Only thing is, at what point does it stop growing. At least when you are using a one controller per view scenario it keeps your focus small and close to that particular view, so the view decides how that particular controller grows.

I use to design by user interface, letting the views tell me what needed to be in the controller but I really want to be more clean and structured and that is why I've been working with CI.

I just get confused, because view-centric design seems easy but looking at controllers in terms of objects per say almost makes me think of each controller as a little app in itself that does many things. Like user/add, user/edit, user/delete, user/profile, user/login, user/logout. At what point do you stop and say wait a minute, why have lots of functionality in one large controller class (which will keep growing with time) when all you need is one method for one view, but you are loading in all that extra controller code that won't be used on that particular request. It just seems to me that by grouping things that might seem logical at first into one controller, down the road it would have been better to be small and discrete.

Maybe I'm just not understanding the approach and why it's good to have all these different methods in one controller. I tend to think in terms of user interface and that drove my design and kept my controllers very narrow and focused (albeit spaghetti code).

For me it comes down to the following scenarios.

1) Design with one controller per view and keep things small and discrete. It would be nice to hear from someone that put this into practice and find out how they liked this philosophy.

2) Design based off objects which normally means looking at your database and creating a controller for each "object" and putting all the functions that can manipulate that object in one controller. Possibly spread across a couple controllers I guess, but to me that's when it gets fishy because I don't think using the model is a good way to represent how your application should be divided up.

3) Create controllers based on the way you logically want to break up your application, that really has nothing to do with how the model is setup. Looking at it through a URL perspective maybe and how to group things together.

The second scenario is where I have the most trouble, because I feel like controllers can easily lose scope and become not what they were intended, like little apps themselves. I'm ready for someones $0.02 on the subject.


Messages In This Thread
I'm at a standstill....need help with controllers (theory) - by El Forum - 08-29-2008, 12:34 PM



Theme © iAndrew 2016 - Forum software by © MyBB