domdafonte's avatar

Controller for every Model?

Do you create a Controller for every model? I have a few tables I feel are best populated by a controller I use for another model and want to get any feedback available on best practice.

A Benefit I see to having a controller to save for each model is simplicity for any new developers who join my project at some future date and wanted to see if anyone had others, or an opinion on this matter..

0 likes
6 replies
Jaytee's avatar

Generally, yes.

If I had an articles system, i'd have a controller and a model. The controller to do the logic and the model to do database stuff.

If i had a PagesController, i wouldn't need a model if i'm just outputting views such as an about me page.

But basically, if you require something to do with a database, you have a controller and model.

mehany's avatar

@domdafonte I think you may find a lot of answers on this forums for this topic, try "laracasts. application structure" in search and see what comes up.

In general, each application has its own criteria and requirement. What the application needs to achieve should inspire the structure in a way or the other. For simple apps ( like blogs, 10 pages website, and such ) those will require no more than a simple MVC and some validation and a database which the framework provides out of the box with ease.

Like Jeffery always says, keep things simple where possible. For instance, having a lot going on in the controller may lead to distraction and unreadable code so some segregation of responsibilities will help avoid that. I make use of request classes to validate the data that gets passed to the controller to avoid writing validation code in the controller. I make use of repositories with modules that do big things where the modules keep only the normal stuff such as queryScopes, relations, etc.. and controllers will receive a request and then return a response.

when it comes to application structure, what works best for your application is the best practice.

2 likes
AOJ's avatar

It is clear for now that irrespective of the number of models you have, you must create corresponding controllers. That will be a lot of work I think. If you consider the basic operations of listing, creating, editing, storing and deleting of items as captured in a controller, it will amount to serious duplication of codes if this operation is repeated for every model in its on associated controller. Its my thought anyway. Imagine you have hundreds of models to deal with. Is it possible that every edit call on a model could have a different coding from an edit call on another model in a different controller or lets say the call to delete an item ? The CRUD operations for each model is similar from my experience and may not not need dedicated controller to handle for each model. If I have a single controller that handles the CRUD business I could simply pass in the name of the table and maybe another parameter, whatever, to perform the operation. Well, its my reasoning . What is your thought on this?

Snapey's avatar

any reasonable sized application will have more controllers than models, and this is a good sign.

You will probably waste a lot of time trying to figure out how to use a single controller to crud multiple models

1 like
AOJ's avatar

You are right Snapey, but if it is possible to get a solution for it, why not do that coding and make it part of the framework for developers to simply call to handle cruds? That question might be for the creators of our dear Laravel.

Please or to participate in this conversation.