CODEWITHSUNDEEP
phplaravelmodelcontroller
lewis4u
lewis4u

Reputation: 15027

laravel do I need a Model and Controller for every single table?

I know this is a duplicate question but i think it will help others because there are a lot of similar apps that have these kind of table relationships:

enter image description here

So the question is what would be the optimal solution for all relationships in this schema using the Eloquent? How many Models and Controllers to make?

Upvotes: 9

Views: 4651

Answers (1)

Arcesilas
Arcesilas

Reputation: 1432

First of all, you need to understand that not all tables in a database represent an entity.

For example, tables like users, posts, comments are entities. Whereas posts_users, comments_posts are not: they are here for technical reason, to materialize the relation between 2 entities.

Only entities need a model: it makes no sense to have a model for a relation table.

Even if a table holds information like date_created, it does not make it an entity. This is just a data related to the relation. For example, the table users_roles may have a column named date_assigned, to know when a given user was assigned a given role. It's not entitity for all that.

Second, you need to understand what a controller is for. The role of a controller is to handle a request and provide a result. Result can be a view, an error (HTTP 404), or just the fact that an action has been successfully done.

You must also make the difference between the class called Controller (or any child that extends this base class) and an actual controller. The actual controller is the code that will handle the request. A Controller class can have more than one method to handle requests.

It's all a question of organization: generally, Controller classes are used to group methods within the same scope: user login, logout, subscription, password reminder are all the same scope. All these controllers could be in different classes or functions. It does not matter. Each method is a controller. They are grouped in the same class because they have the same needs (check user is logged in, to know if login is required, if subscription page can be displayed, etc.) and they are in the same scope, which just make sense when you think of it. That's just logical: you know where to search when you need to change something about user identification (even if you are new on the project).

So you need a model for these entities:

  • User
  • Offer
  • Invoice
  • Category

The controllers you'll need depends on what you want/need to do with this data. There's no ready-to-use answer to this part of your question.

Use a Controller class for:

  • user authentication (if you need some)
  • user management (backoffice)
  • invoice management (edit, mark paid, list of late payments, etc.)
  • categories management (create, edit, delete)
  • offers management

But depending on your application, you may need more. Only you can really say. There's no bad answer to this question: if you think some controllers should be separated for better organization, do it. If you think you should group 2 or more, do it. There's no rule. You have to keep your code clear and well organized. It must suit your needs. That's all.

Upvotes: 21

Related Questions