Welcome Guest, Not a member yet? Register   Sign In
How do you decide what makes a controller?
#1

[eluser]jleequeen[/eluser]
Hello all,

I'm in the process of migrating a legacy app to CI. The app is basically a typical spaghetti page based approach. I'm trying to figuring out what controllers I'll be needing to define. I understand the MVC concept fairly well, and I've asked in the past questions on this subject, but I typically get the same answers, "it's up to the individual", which I understand to a degree. I'm just curious how you decide what to make a controller and what not to. Let me give a quick example of a situation:

I have a login.php file for main application login for a regular user. Then I have a login-admin.php file for logging in as an admin. Now I could either..create a user controller and put a login action in it, or I could create a login controller and have an action for each type of user. To me... user/login makes sense, but I don't know if the controllers=noun actions=verbs works in all cases.

Maybe my whole thinking on the subject is wrong. Perhaps if my application has 10 spaghetti files in it, and they are not really related, then I would need 10 separate controllers and associated views for each and I'd basically be utilizing MVC separation which is what CI is all about in the first place. I'm aware that you could just create a group of related pages under one controller and make each action a "page". Any thoughts?
#2

[eluser]gtech[/eluser]
I tend to group controllers by database tables. I see each database table (apart from the lookups) as an object, which might be users,customers,orders,invoices or whatever. Then each model I create tends to map to a database table with functions that correlate to that table, for example create_user, delete_user, edit_user. You will probably get functions that might belong in both models for example add_user_to_customer, I then make a decision on which model it belongs as long as I am consistent. then what I do is tend to group each controller by the model names.. so you have a users, customers, orders ... controller, again you will get crossovers as some pages may require more that one model to be loaded.

This is a process that has worked for me for the type of application I have been developing, however it may not be appropriate for all circumstances.

You have to sit down with a piece of paper as design how it will fit together.. I recommend starting from the database and things should start slotting into place.
#3

[eluser]jleequeen[/eluser]
@gtech

I think that makes a lot of sense. I can see how that would work for some or most applications. I guess mostly when I think about controllers I think about objects, like users, customers, orders, etc. And each method like you said, being what those objects can do. Where I have the most trouble it seems is when you might need a controller that isn't necessarily an object. Or, say your user controller is going to be so big that you want to break it down a bit. And also confusing is for example: You have a orders controller. It does a certain amount of things. Then you have a customers controller. Part of the customers actions would obviously be to place an order. Would that function go into the customers or orders controller? I would think orders (because your creating a new record in that table), but you can see what i'm talking about. Maybe your way of thinking about it from a database standpoint makes things a little easier to understand. Thinking of it in those terms might be just what I need. Thanks for your comments.
#4

[eluser]xwero[/eluser]
I look at controllers as the outside links. How do i want the data to be reached. In the case of your order example i would put it in the customer controller because it's the customer that enters the order. Models don't need to be linked to one model or models only need to be linked to on table but to make it more maintainable i add a comment near the top of the file which models are used and which tables are used if there is more than one. In a model the necessity is bigger because i'm using fat models.
#5

[eluser]jleequeen[/eluser]
@xwero

I see what your saying, but to me it seems as though the controller would get very big because your kind of deciding breaking the controller up by user type instead of objects. It seems like if I had a user, and he could do basically every function in the system, then it would all be in the user controller. For some systems that might work fine, but it just seems like it would get awful "fat" as you said about your models. I do agree though, it makes some sense to do things that way because it works well with the actions to have user/login or user/orders (the noun/verb). I just want to make sure I have a consistent approach that makes sense that's why I'm struggling with this concept a bit.
#6

[eluser]xwero[/eluser]
If you use roles you can split up the functionality on what is possible for the role. Translated into filestructure you have a directory role with the controllers superadmin, author, commenter, ...

My controllers don't get fat because i use the magic of convenience. My controller methods contain little or minimal code, this way i can put a lot more methods in the controller without losing the oversight.
#7

[eluser]xwero[/eluser]
Of course if you are creating an intranet site, you can create your controllers based on the functionality.
#8

[eluser]jleequeen[/eluser]
@xwero

I've been reading the post you recommended and looking at your code in the wiki. I like your ideas, I'm just trying to wrap my head around them.

If i were to use roles to split up functionality, and basically had a controller for each role how would I implement actions that would need to be shared between roles. For instance, I might have a user and an admin that can do the same things. It seems as though duplicating methods between the controllers might be inefficient. Maybe I'm missing something though. I do appreciate your ideas and comments. Also, I do hope some of your work gets added into a future release of CI.
#9

[eluser]xwero[/eluser]
Duplicating isn't needed because the links to the functionality are only visible based on the roles the user has. Let's say a user can add and update a page and an admin can delete a page. In the page overview the link to the delete functionality only shows when the logged in user has an admin role.

To keep the url clean you could use routing but i don't think it matters much if the url is role/user/add and role/admin/delete instead of /add and /delete. In fact it adds visual conformation in which role the user is doing something.




Theme © iAndrew 2016 - Forum software by © MyBB