Two things get confused constantly: the Repository Pattern gets used without anyone explaining what it actually is, and Dependency Inversion (a design principle) gets treated as the same thing as Dependency Injection (a technique), when they're genuinely different ideas that happen to work together. This post explains both properly, then builds one complete example, a small library book reservation system, and walks through exactly where each of the five SOLID principles shows up in that one piece of code, with an analogy and a concrete "how it's achieved" for each.
What the Repository Pattern Actually Is
A repository is a class whose only job is talking to a data source, a database, an API, a file, whatever it happens to be, and handing back plain objects. Everything else in the application, business logic, services, controllers, talks to the repository, never to the data source directly.
Think of a librarian. You don't walk into the archive room and dig through the shelves yourself. You ask the librarian, "get me this book," and they know exactly where it is and how to retrieve it. You don't need to know how the archive is organized internally, alphabetically, by genre, by acquisition date, none of that is your concern. The repository is the librarian. Your business logic is the visitor asking for a book.
