Dilemma on separation of concern and design patterns

Imo in Laravel eloquent is almost a repo style pattern.

Meaning why call a repos create method when you can call the models create directly? Seems like needless extras. With the db drivers supplied it all but debunks the swapping db argument.

With that said in small to medium sized apps I tend to just call eloquent queries in the controller. If it's a large, very specific or reused query out of a basic one I'll set it in the model or trait to the model. Utilizing a scope, function or what have you.

Seems we all over engineer things to make it more complicated then it needs. Calling ten functions that don't get used anywhere else just seems more complicated later. It really doesn't help with anything. If it's not reused anywhere else who cares?

The only sticking point I run with is consistency. If you fire events in a controller, try to fire them all from a controller for example. Trying to track things down is a pain later otherwise. If to utilize model functions and eloquent in your controller try to do it all the time. Then a year later when you're adding a feature or updating one it's easier to track things down.

Also i've come across write-ups from industry pundits that says the Repository patterns is not necessary for all use cases

If you are not doing a large Fedex size site just follow Taylors examples, will work fine "out of the box".

@jlrdw...lol one doesn't have to be building a large Fedex size site to adhere to good programming principles

@jekinney I noticed your blatant criticism of the entire Repository pattern for laravel on many laracast posts so this is no surprise..lol...I also agree that the Eloquent models are in themselves a repository. Look at this example for instance. If I have a Users model that extends Eloquent. Instead of calling Users::create() from say a controller, I can easily create a createUser() method in the Users model and just receive data on that method. This way, if I plan on changing from Eloquent to something else tomorrow, I simply need to go to the Users table, and remove the extends Eloquent to what i'm using now and just change the implementation of the Users::createUser() method to call the create method of the new ORM. This way i'm never calling Users::create from anywhere but Users::createUser() which is my single method for creating User. Doing this I don't think I need to add a Repository then. Make sense?

An answer I just gave on another post:

I also came from java, beans, jsp, servlets. Remember one thing core java / servlets have longer backwards compatibility than a php framework. I tryed some code I wrote 10 years ago in the latest java ee and it works. But of course that doesn't mean it wouldn't need some enhancements, like modern security, better css, html5, etc. Javascript frontends are totally optional.

A site can be completely done with laravel with html5 and just a little javascript for enhancing things, i.e., a popup calendar, a popup lookup table, etc. I used a lookup table mainly to fill in shipper / receiver info at a trucking co. I actually used the old ajax code before learning jquery. Jquery made life so much easier.

Then I look at Bootstrap

Just css, optional, I write my own css.

Remember, this is a wowed latest technie forum for the most part. If you talk to a main programmer for a State Government vs a programmer here, you will get two view points. For example there are secure forms on State of Texas Health and Human Services sites where javascript isn't even allowed. I like javascript, but sparingly.

Also

to adhere to good programming principles

So following Taylors examples is not good you say, I like his examples and the way laravel works out of the box.

Weather repository or controller, code runs the freaking same. It would run the exact same in a non mvc single page app as far as that goes. Seperation is for the human, processor could care a rats a__ where it comes from.

Way to much thought in it, how in the world did large sites exist in java technologies years and years before laravel existed. FAT servlets somehow did just fine.

@jlrdw If you notice when discussing issues like separation of concern, thin controller -> fat models etc, people tend to be so confused as to where certain logic should go to. You know where this confusion comes from? Instructions giving to beginners in books and video tutorials. When I started coding in MVC some years ago, all reference books and tutorials I read always gave examples of controller actions and they had stuff like form validation there. So imagine waking up after 6 months of doing it this way and someone tells you your controller is too big and should only be 1 line? It makes you hate yourself for thinking you were doing the right thing all those years. This is the problem I have with when tutors and framework authors write documentation. This is what really drew me to Symfony 1.4 because it is very opinionated. Certain files go to certain places. Each model had 2 files. For instance User.class.php and UserTable.class.php. So you knew the UserTable class was the collection (or repository) and the User class was the Model. So properties and functions particular to every instance of that model are defined here while functions used to fetch those instances are defined in UserTable class. I think the whole concept of Non-opinionated in framework design is a bad idea. You should make sure everybody adheres to a particular way of doing things and by your design, projects would be scalable and maintainable

Also any one noticed an issue with the comment box here, whenever I type in a comment and click submit, i'm redirected to an error page and I have to click back and resubmit for it to work

Lol @ghostpunter dang it! You know me to well!!

I look at it the same as you mentioned.

Though what's the difference from create? If you remove eloquent you can create a create method? I still get your point though.

@jekinney the difference is that you can then place other operations that need to occur when a User object is created like say send an email, fire an event etc where's if you just keep calling Eloquent models then you would need to call each action that should be performed after every time