Support the ongoing development of Laravel.io →
Database Eloquent Architecture
Last updated 2 years ago.
0

Its common to have the your controllers very thin, so they are easy readable and are more SOLID-like.

On the other Hand it might just depend on what you prefer, because neither change anything in terms of performance.

Last updated 2 years ago.
0

Maybe you should look into repositories pattern. It would be great place to put that logic because Eloquent model is more like db reflection and shouldn't be doing much logic (except getters setters, scopes) and controllers shouldn't be aware of db at all (It just cares that required data from somewhere is provided). So it just tells repository -> get this data for me please. And repository than works with Eloquent (or MongoDB or some service) and makes search query. Basically there is abstraction layer (repository) between your app and data storage (Eloquent in this case).

Maybe if it is small app, repository pattern is unnecessary. But for my projects i always use repository pattern (habit i guess).

About that thing: "even though they are only called from one controller".

I wouldn't relay on that. If it's your private project maybe you know for 100% that it will only be in one place, and still after some time, there would be need of an similar search somewhere else. And if it is project for client there is even more ambiguity. There were few times when i was depending on that it wouldn't be used anywhere else, but it did (few sleepless nights taught me never ever relay on that).

Good luck :)

Last updated 2 years ago.
0

revati said:

Maybe you should look into repositories pattern.

I want to upvote this ;) A repository class is what needs to be used. Maybe this can help:

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

Last updated 2 years ago.
0

I have read up on the repositories pattern, and I agree that it's a great way to set up your application, and keep both Controllers and Models clean of code, with the added perk of much easier testing. I will most definitely try it out, thanks for the recommendation!

As a side note, I have an upcoming project after this one, where different clients need different data storage (like, one client getting data from a database, but the other from a web service / textfile / whatever, with both clients using the same controllers / views). I wasn't quite sure how to solve this in a good way, but using repositories and just swapping them out depending on the client solves everything very neatly. Two birds with one stone on this question :)

@Faiawuks, great read, thank you!

Last updated 2 years ago.
0

I am just now porting our in-house CMS using laravel and eloquent but since i am already using a completly custom MVC based solution i found that the best solution was to keep such things out of my controllers and out of my models as well! i called them ModelManagers. Don't really care what pattern this follows or if you can call it a repository or a factory or a collection. It was basically a layer between my controllers and my models

So if i had my controller PropertiesController would talk to the PropertiesManager which it turn would talk to my Property Model.

This was a very convenient solution since PropertiesManager had all the code necessary to grab a single item or a collection of items. Or do complicated things still like searching for properties via 5-6 different models associated with it. (types,categories,features,country,location and other basic property attributes)

e.g. when you did a search on properties the controller would call the properties manager passing all the search variables and the manager would return a collection of data nicely packaged in an array with the returned properties models and all their related models or data necessary to populate my views. the controller would then pass the data to my views.

Last updated 2 years ago.
0

@unitedworx, that sounds pretty much identical to the repository pattern suggested above. One clever detail explained in the link above (that maybe you're using too) is the use of bindings and interfaces to very easily swap out the managers, even during runtime. But yes, I agree it seems like a very good way of designing an application, I will definitely do that for the next one :)

Last updated 2 years ago.
0

@ErikEklund i figured it's the repository pattern i am using after following the above link :) i am looking into this pattern further now and checking out the best practices are in regards to Laravel.

There is a nice tutorial here which is simple and to the point https://laracasts.com/lessons/repositories-simplified

Last updated 2 years ago.
0

Sign in to participate in this thread!

Eventy

Your banner here too?

ErikEklund erikeklund Joined 14 Jun 2014

Moderators

We'd like to thank these amazing companies for supporting us

Your logo here?

Laravel.io

The Laravel portal for problem solving, knowledge sharing and community building.

© 2024 Laravel.io - All rights reserved.