- https://www.youtube.com/watch?v=9A26ybw6tGY
- https://www.youtube.com/watch?v=5HahAQ6V35k
- https://www.youtube.com/watch?v=93ZhGkFIwbA
- https://www.youtube.com/watch?v=rtXpYpZdOzM
- https://www.youtube.com/watch?v=x6C20zhZHw
- https://www.youtube.com/watch?v=AQDIF4bB4BE
- https://www.youtube.com/watch?v=D7nAGC4DN08
- https://www.youtube.com/watch?v=giJcdfW2wC8
- https://www.youtube.com/watch?v=qwMQPgdgwYI
- https://www.youtube.com/watch?v=eeGSxhABNyI
- https://www.youtube.com/watch?v=8rXbkGyWK4o
- https://www.youtube.com/watch?v=9dBq7_LBIlQ
- https://www.youtube.com/watch?v=D7nAGC4DN08
- https://www.youtube.com/watch?v=9HN7eVjj33o
- https://www.youtube.com/watch?v=AHVtOJDTx0M
- https://www.youtube.com/watch?v=RDJoGfCibCc
---
- Use the "Repository Pattern" to keep the Models thin where one writes only its relationships (working as Entity) and the mutators/accessors. Commonly having an Interface, even for only one implementation. This concept does not allow updating and deleting on the repository - as this should be handled directly in the Model.
- The repository pattern adds a layer of complexity not needed for every project. Start off from the bottom up, and scale into the repository pattern (e.g. making use of query scopes first).
- Using the repository pattern with Laravel Eloquent models really doesn't make sense because the Eloquent models are active models: Eloquent is an implementation of the active record pattern. The repository pattern makes more sense in the context of traditional POPO (plain old PHP object) models. Such models don't have to come from a database at all, or if they do come from a database they generally are managed through an object-relational mapper implementation. The main reason to use the repository pattern with Eloquent would be, to allow for switching database implementation entirely this is unlikely in most projects. Furthermore, it actually doesn't really separate the implementation satisfactorily so it really doesn't make sense in the context of a project using the active record pattern.
- When deciding your repository, a decision needs to be made for keeping collections either inside the repository or outside the repository. If inside, then it should always return (using an interface) the same type that is mapped on either data source, this is easier to manage but requires more data type-specific logic in the repository. It's a bit funny if one ends up using collections later on (as it will have to be re-injected). Keeping it outside, it will always map a collection to the data type (basically introducing an adopter at some point). At this point, the programmer ends up managing two layers; inside the repository is a collection, and then outside the repository is a service that will continue using that collection. In the other method, the service purely manages the business logic and nothing else.