– https://www.facebook.com/ifeora.okechukwu • GitHub – https://www.github.com/isocroft • LinkedIn – https://www.linkedin.com/in/ifeora-okechukwu-a3b30b69 Music Enthusiast, Marvel Fan-boy, Unrepentant Internet Addict, Open- Source Junkie and Developer Advocate & Paramount Doer at #Coolcodes https://web.facebook.com/coolcodes . I Work for Oparand as Technical Lead. #BestPractices #WebApplications #ScalableArchitecture
to a commonly occurring problem in software design and implementation. There are 3 broad categories: 1. Creational e.g Singleton, Abstract Factory 2. Structural e.g. Repository, Façade 3. Behavioral e.g. Composite, Visitor Repository pattern is of the Structural coding pattern family. It is actually a special kind of Façade (highly specialzed) for data access and transformation. A repository (which is the outcome of implementing the pattern in code) mediates between the domain-layer and the data-mappers (relational or not).
benefits to using the repository coding pattern as an added layer in MVC structured applications like Laravel. 1. If you use ORMs (Doctrine / Eloquent), when properly abstracted out, you can swap ORMs without affecting the interface through which your business logic interacts with your data access/storage logic. 2. When implemented properly using interface/abstract class type-hints and extension APIs, repositories are very easily testable using mocks. 3. Using other coding patterns with repositories is also very easy like the Adapter and Decorator patterns.
to a storage location, often for safety or preservation. In Laravel, repositories act as both a factory and a collection store which filter and transform data units. This is made possible because repositories are powered by ORMs (Doctrine / Eloquent) making it possible to hide/abstract complex implementation details for database queries. In a multi-layered architecture, repositories belong to the application-service layer. Repositories should be completely isolated (i.e. loosely coupled) from the details of the business logic (which reside in the domain layer) using the SOLID pattern popularized by Robert C. Martin (Uncle Bob). Repositories should have singular tasks (i.e. they do one thing only). They should have at most one Model (in an MVC setting). When you require to use more than one model (e.g. for join queries), you should use a decorator. Repositories should only be instantiated as singletons and never in any other way.
to setup repositories from scratch (in fact it is a pain). Owing to this, it’s a nice thing to have the boiler plate code as a packaged snippet. For this purpose, a particular composer package comes to mind – bosnadev/repositories You can use other complimentary packages like – watson/rememberable
1. Collection-Oriented Repositories: These are repositories structured and created to operate as in-memory array/dictionary store. (e.g repositories powered by riak, memcached) 2. Persistence-Oriented Repositories: These are repositories structured and created to operate as persistent entity stores. (e.g repositories powered by ORMs – Eloquent, Doctrine)
a specification of a set of conditions and/or filters that MUST be met before a repository can return data collections based on the requirements of the domain-layer at any point in time. One or more Criteria can be applied to the repository to create complex set of conditions. Criteria make it possible to reuse these conditions and/or filter in multiple repositories.