Pattern-Friends!

@konstruktionsplan

My understanding of your question is, it totally depends on your project rules and company practice.

As I know, in the PHP community, the widely used design pattern is SOLID.

Of course, it is mostly project dependent. But I like to use the repository pattern, for example, because I find it much "cleaner".

@konstruktionsplan

In my honest opinion, it's another important pattern to make maintainable code.

Personally I use the Repository pattern also in my many projects.

Then use it. I never really think about what pattern to use. I just TDD my way into the code and refactor where needed. The only rule I follow as if it were a law is the KISS.

Unless there is a requirement to use a certain pattern.

The best pattern for me is to start the day with a plan. Describe the goal(s) and follow it to a tee.

BTW I do enjoy the command bus pattern; every action/process into a command :: laravel job

@konstruktionsplan What do you like about the repository pattern? I was recently reading up on it and it seems like the only benefit is to bridge between Models and Controllers as a way to make things ORM agnostic. Which, I don't find very valuable. I get it, I just don't really see value in it. Same as naming routes... I get that it moves a certain amount of changes into one place... but I also know my applications well enough to never have to worry about refactoring and apps naming conventions on routes... nor do I hold a great concern that Eloquent is going to be abandoned anytime soon.

Let me know your thoughts about it and what you think the benefits are. Why is it cleaner?

Hey @fylzero

Example:

I have many blog entries. These are displayed in the frontend and of course in the backend. (So more or less classic WordPress).

Now I would have to write something banal like "return Post::all();" in the WelcomeController@index.

I would have to do the same in the DashboardController@showAllPosts.

But at some point I get the idea that loading all entries will destroy the world. In your case I would have to open every controller and change every line. The homie with the repo, however, changes it only in one place for all controllers, because he injected the interface of the repo into the constructor via DI.

If I ever change to another database model, I have to go through the whole project to change it.

@konstruktionsplan Yeah, I just don't agree that is painful. Doing a search and replace on a codebase to replace Post:: with SomethingElse:: just doesn't seem like a big deal. Also, if you're changing the model, I mean, isn't it more expressive to actually change it? idk, I just never saw the real value in obfuscating named things for this reason. If I ever changed them, my OCD would want to go through the codebase anyway. I guess maybe that doesn't scale in certain cases, but I've run some fairly large projects and have never liked doing things like this.

To each their own. :) I am open to changing my opinion on this, btw. I've actually been really curious about the benefits of this approach... but what you've laid out is exactly why I feel it isn't a really powerful change.