Do I need a repository for Eloquent??

Question

Laravel

Everyone will accept. I recently read several articles on the implementation of the repository pattern in the Laravel framework. It became clear to me how to implement the pattern itself, but it is absolutely incomprehensible whether this pattern makes sense if in all examples Eloquent is used as an access point to the database?
I understand the point of creating a repository for QueryBuilder. This will just allow me to separate the query logic from the business logic located in my services, but is this necessary with Artive Record? After all, it seemed to me that the Eloquent models already, in principle, themselves perform something like a repository? That is, they have their own basic user-friendly interface that can be extended with local and global scopes. And if this can be done, but it is not clear why then a separate layer is needed that will do the same...
They also say that this will allow you to change the type of data storage. But it's not clear to me either. After all, if I use ORM, then it determines to some extent the data output format. For example, adjacent Eloquent tables are nested objects within an object. That is, even when outputting an array, we will get nesting, which will be incompatible even with QueryBuilder, and adapting a big date and bringing it to some output format is a thankless task. And if you think about Redis, then most projects, in principle, cannot be transferred to non-relational databases.
So here's the question. From all of the above, it is not clear to me why the repository pattern is needed on top of Eloquent. Can someone share their opinion on this and about when repositories really became useful to you, even if they work not through Eloquent, but through native SQL queries or something like that ...

Answer 1

The point is, if you're not 100% sure you need the repository pattern, then you don't need it. Otherwise, you will get an extra layer of abstraction, a mountain of copy-paste and duplication of the same Eloquent.
I advise the master class on DDD (in the second part about the repository), it explains why many things are needed.

Answer 2

Here is another article https://m.habr.com/post/316836/
I personally abandoned the repository with eloquent

Answer 3

Eloquent does a great job of being a simple and more or less efficient ORM for CRUD projects and so on.
Of course, more complex queries are often needed and they are allocated either into scopes in the model itself or into separate classes that build queries.
When the tasks become even more difficult, when we need to divide our entire model into read and write parts, Eloquent already starts to piss me off :) Plus, the inability to separate the logic of the model class from the logic of storing it in the database starts to strain on any models more than one line in the database. As a result, in those projects in which we want to separate the Domain logic from everything else (including the database), it is much more profitable to move away from it.
We need all these repositories just for this, in order to abstract and separate the logic of storing domain logic objects somewhere. And with Eloquent, this is almost impossible. I will analyze this in detail in the book, which has already been advertised here - https://leanpub.com/architecture-of-complex-web-ap... Selecting
classes for some query building is quite normal for projects with Eloquent. That's just not to get involved is desirable. Sometimes people suffer terribly with these eloquent builders, when it's easier to simply write a raw SQL query. Usually this applies to any reports where there are a lot of different interesting aggregations with groupings, etc.

Answer 4

Eloquent - it already has a repository for QueryBuilder

Answer 5

Even you chaotically wrote and mixed different things.
Laravel has separate convenient tools / wrappers for working with the database , and a separate thing is the Eloquent ORM built on the principles (anti or not) of the ActiveRecord pattern.
So, it means that you use wrappers over the database and implement / use a convenient approach / pattern for organizing models. In general, I advise you to leave Eloquent if the project develops in the future and / or if it will be led by several people, as fermentation of Eloquent property models and methods begins in the project, which ultimately leads to more difficult debugging, development of changes / adding editing properties and so on and so forth. Of course, if the project is simple, without super logic, and you know that everything will be simple further, then you don’t have to worry.
Well, I advise you to study and read this comment on the toaster directly on this topic:
https://toster.ru/answer?answer_id=1127442#answers...