There is nothing about the repository pattern and dependency injection that is mutually exclusive.
The primary purpose of the Repository Pattern (example) is to divorce your application logic from having to know anything about how to access the data. Whether the Repository uses ORM, an Object Database directly, or just stores files on disk, are simply implementation details of the Repository itself.
The Repository Pattern is used in a few architectural patterns like:
- Onion Architecture
- And similar
The Repository Pattern also allows you to architect Command/Query separation so that how you look up data does not have to match how you store data. It's not uncommon for your data needs to grow, while still supporting your application logic. For example:
- Your project starts with only a traditional RDBMS (SQL database)
- You add a search layer to optimize faceted search (Elastic Search or Apache SOLR)
- You add caching to improve response times
- You add a graph database to perform friends of friends searches
All of these concerns are implementation details for how to store and retrieve data. You shouldn't have to recode the rest of your application to support all of these approaches.
Do I Need the Repository Pattern?
That really depends on your project. If you are simply doing a research project for school, or a one-off tool to do a specific job, then probably not.
If you need the flexibility to improve your data access story over time without breaking your application, it's a good tool.