Eloquent implements the ActiveRecord pattern, which basically implies that it is an entity that wraps a single row in a database.

So from a purest point of view if your model behaviour returns a single row then it is fine to add it to the Eloquent Model class.

Now depending on the size of your application you can use your models directly in your controller and use the fluent interface of Eloquent to do your logic. This does imply that you have an Eloquent dependancy inside your controllers.

// Inside the controller
return view('...')->with('posts', Posts::where('author', 1)->get());

Depending on the size of the application it is sometimes useful to add another layer of extraction where you use a Repository inside your controller, where the repository returns collections of objects. What makes this nice is that the dependancies inside the controllers can then adhere to a repository interface which in turn are swopable, so you could have an EloquentRepository or a NoSQLRepository etc. It could be something like this inside the controller,

public function __construct(PostRepositoryInterface $postRepository)
{
    $this->postRepository = $postRepository;
}

public function posts()
{
    return view('posts.list')->with('posts', $this->postRepository->findByAuthor(1));
}

One could also introduce another layer where you could have Service classes (a very generic term) which consumes Repositories, does a whole lot on the collection and returns just what is required.

I do agree with you that you do not want the implementations of showDestinationState floating around inside the controller. In the end you do what feels right for you considering the size of the app. No need to have repositories and alternative service layers for a smaller app. Eloquent with the query builder can work great inside the controller.

Also with what you do, I as an example, do not really like static calls so I personally stay away from them, but that is personal taste.

Something else, the M for MVC does not just refer to an Eloquent class. The Model could comprise of a couple of classes and is a separation layer. So the Model (whatever that might be) does not know anything about the UI layer.

Thanks heaps for response, its a great explanation for me. As you said the Active Record pattern kind of takes care of this for you from the controller.

However having everything inside the Model is working well for me and I seem to have developed a bit of a system now.

As i'm learning Laravel and OOP for that matter I think i'll stick with what works for me and as I progress my skills. I just want to know if I'm on the right track??

As i'm still also learning design patterns...Is this what I am building... a repository as you mentioned? I read the definition you linked and it sounds like one.

As basically I am grouping all my logic into a method, deciding what to do with as a query or validations and returning groups of objects as arrays back to my controller

As you mentioned laracast in your post I seem to remember a couple of laracasts he did specifically on repositories when you decide for more flexibility and better testing.

Thanks, yes i'll be checking them out when I get a bit more comfortable

In an laracast episode, as I remember, Jeffery mentions that you can just add the Model directory back but he also goes on that most larger applications do not necessarily end with just "models" but rather that you should also consider domains and business logic.

I came from a clear and distinct MVC framework before laravel on top of hating my models floating in the app directory promptly added the Models directory back ;-)

@ lvismer Awesome explanation! That helped me understand even more why filling my controllers with eloquent isn't an evil thing to do.

@ repositories I completely get the idea but if your application is going to be running on my database anyway (more than likely a mysql derivative) than why add this extra layer to an app? I should say that it seems like another layer that slows down the application. I would love to be wrong about this and in turn remove the main reason why I don't spend the time making an extra 2 files per controller.