Code like this doesn't belong in a controller or a model.

You could use the Repository pattern, which will keep both your controllers and models tidy.

Here's a good example:

http://heera.it/laravel-repository-pattern

Thanks, but isn't all database manipulation should belong to a model file not controller? What about rule: "Fat model and skinny controller"?

If you want to follow the "Fat model, skinny controller" pattern, you'll end up with difficult to read models. But it depends on the size of your application....

The ideal is skinny model, skinny controller & skinny repository.

In terms of Laravel, a model uses Eloquent, which means it's tied to a database. The model takes care of events, query scopes, relationships - those are things tied to getting data from a database - which is fine.

But adding business logic to your Eloquent model will quickly make them difficult to read. Plus, it's likely you'll be saving data from other models and that gets messy FAST, so you're mixing up data from one model into another which confuses the purpose of that model.

So, adding another concern to an Eloquent model is a Bad Idea.

One solution to this is to separate your business logic from both your model and controller, and in the end, hide the fact where your data even comes from via the use of repository pattern.

The end result of using a repository is that both your views and controllers don't know whether the repository is handling data from a database, an API or from a text file - because your repository (and ideally, a corresponding interface to match) hides that detail.

The other benefits are that the repository handles one task and only one task - meaning you can quickly adapt and amend that code in future - and you can be confident that your controllers and views won't break as easily. And, importantly, your models stay skinny - focusing purely on what they were originally intended for.

Personally, I find this pattern works. It's not perfect, but it helps give clarity on larger projects.

I agree with @jayhealey here, the repository pattern works very well in cases like this. I haven't actually done much with Laravel yet, but with other frameworks I generally do validation in the model (as it's part of the domain logic) and database stuff in a repository. Your controllers should be very light and not have much logic in them. Controllers should know absolutely nothing about your data model, all data access should go via repositories.

So can you guys summary it for me please:

1. Views - is for displaying data (i know this)
2. Controller - all routing logic should be here in order to not overload routes.php? Also there should be no validation, right?
3. Model - is generally for relations between another models?
4. Repository - here goes all business logic, like saving data in to a database, that's it?

I think you're close. The model is interacting with the database (reading, writing, etc) and yes it's the best place to establish relationships with other models. The model is the one saving to the database, however you can inject the model into your repositories making it a dependency of the repo. Then the repository is using this object (model) that was injected into it to save data to the database. The repository is not interacting with the database directly, its doing it through the model. Instead of injecting an Eloquent model into the repo you could inject a mock object, and the repository wouldn't care.

Off topic:

You could use the Repository pattern, which will keep both your controllers and models tidy.

I just read this sentence and remembered the days when:

• Fat controllers and slim models
• Fat models and slim controllers

Both parties were standing and falling for their believes.

And now it is like nah, slim controllers, slim models and fat repositories.

But Repository pattern is realy great :)

@revati I laugh about this too. And that was only two years ago.