π¦ Repository Pattern
This is a practical and real-life example of how to use the Repository Pattern
with Dependency Injection
to manipulate with the database like a PRO. π
What is a Repository Pattern? π€
Repositories are classes
or components
that encapsulate the logic needed to access data sources. They centralize common data access functionality, providing better maintainability and decoupling the infrastructure or technology used to access databases. This allows us to change the Database used at any time, either from a MySQL
to a MongoDB
without further complexity.
As you have to visualize Repository
corresponds to the interface, that is, the contract that the specific implementations have to fulfill. In this case MongoRepository
, MySQLRepository
, PostgreRepository
.
Note: Whenever we want to add a new implementation (another database) we must implement this interface.
What is a Dependency Injection? π
Dependency Injection allows objects to be supplied to a class instead of the class itself creating those objects. These objects fulfill contracts (Interfaces) that our classes need in order to function.
Define our interface.
// Define our interfaces/contract
interface Repository<T = any> {
create(data: T, query?: Query): Promise<T>
// Other methods...
}
Define our implementations.
class MongoRepository implements Repository {
async create(data: any, query?: Query): Promise<any> {
// Do something...
}
}
class MySQLRepository implements Repository {
async create(data: any, query?: Query): Promise<any> {
// Do something...
}
}
Define our client.
class Controller {
constructor (repository: Repository) {}
}
// Using MongoDB π
new Controller(new MongoRepository())
// Using MySQL π¬
new Controller(new MySQLRepository())
As you may have noticed, in this way we can change the database quite easily, since our Controller
client does not depend on its specific implementations, but on a Repository
interface.
Top comments (6)
Thanks for the post. I think it is possible to use the repository pattern you suggest. But is it really a good idea to try to switch between relational databases and no-SQL DBs? IMHO, you are forced to reduce your interfaceβs capabilities to the least common denominator. No chance to use the great freedom of throwing documents at your interface as you could if you just had a no-SQL interface in mind. What about optimization/sharding, clustering, etc.?
Seems to be a more theoretical thing rather than a real-world requirement to switch between all kinds of DBs.
Thank you for the comments, bro. π
The publication does not intend at any time to suggest such changes. What it intends is to minimize the dependencies that may exist in our projects. That instead of depending on
concrete implementations
, they depend on an abstraction(interface/contract)
Grettings. π
thanks for the post! I do miss some example usages of you actually implement this in code.
Thanks, bro!
You can take a look at this example: github.com/TheBugWeb/todo-express-...
We use this pattern at work for a microservice. It makes more sense now! Thanks
Thanks! I was always curious about this.