Aspnetcore.docs: Don't implement repository

[dlidstrom]

To anybody reading this, please consider not using repository pattern at all. It will lead to excessive mocking in your tests which will tie your internal architecture with your tests, leading to a solution that will be hard to change.
Instead, rely on the in-memory database for your tests which (if done right) is a 100% simulation of running for real. That will give you the most benefits from your tests and also much simpler DI setup (you basically only need a way to access a request-scoped data context). I would go as far as to say the Repository Pattern is an anti pattern.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 70abf2e3-3f75-2a00-2c10-5895306d9392
• Version Independent ID: 5a0f70f2-02f4-dfc2-f89e-ca3a374c82bb
• Content: Repository pattern with ASP.NET Core
• Content Source: aspnetcore/fundamentals/repository-pattern.md
• Product: aspnet-core
• GitHub Login: @ardalis
• Microsoft Alias: riande

[guardrex]

Thanks for your comment @dlidstrom.

Management made a decision a while back to generally not use the repository pattern for our samples any longer. There was a lively debate about it! :smile:

Some of the topic samples still use it. I'm upgrading the Testing controllers sample now to 2.1, and it happens to use the pattern.

We moved content on the pattern to a dedicated topic for those who wish to use the approach. That topic lives in the Fundamentals area: https://docs.microsoft.com/aspnet/core/fundamentals/repository-pattern

As we go forward, fewer-and-fewer samples will use the pattern. It will probably be factored out when new samples replace old samples. It will probably take a while tho for it to totally disappear from topic samples.

[dlidstrom]

Thanks for the quick response! I'm happy to see that this will be factored out. I've had so much trouble over the years in projects that overdesigned this pattern totally unnecessarily. Nice to know you too agree with this. You can close this as far as I'm concerned.

[CESARDELATORRE]

Hi! - This is Cesar de la Torre, PM at the .NET team in Microsoft Corp. and author of this book focusing on Microservices architecture implemented with .NET Core: https://aka.ms/microservicesebook

I don't agree on this recommendation saying that the Repository pattern is ALWAYS an anti-pattern.
It is a pattern that shouldn't be used in all apps, I agree on that. But for certain applications like the transactional area of a Domain-Driven Design application the Repository pattern is a good recommendation as it acts as a "guard" for the transactional operations made against entity AGGREGATES. It is a 1:1 relationship between each AGGREGATE-ROOT and a single REPOSITORY.

However, I agree that in many simpler web apps or simpler microservices/Web APIs that are more Data-Driven as opposed to Domain-Driven Design, you don't need to use Repositories. In fact, I recommend not to use Repositories for simpler scenarios in the same way that I recommend not to use AGGREGATES or many other DDD patterns for simple data-driven apps (CRUD app, etc.).

Here you can see a few explanations on why Repositories are useful for the Domain-Driven Design areas in an application.
Take into account that this doc is targeting a Domain-Driven Design oriented microservice:
https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/infrastructure-persistence-layer-design

In this other content, however, it is targeting simpler data-driven microservices (such as CRUD) where we don't recommend to use Repositories but to use EF code directly:
https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/multi-container-microservice-net-applications/data-driven-crud-microservice

MY POINT: Patterns and anti-patterns depend on the type of application or service you are building.
A good pattern for building a truck is an anti-pattern when building a bike, and viceversa.
In general I try to avoid to say: "dot not use repository pattern at all" or "This or that is always an ANTI-PATTERN or a PATTERN". :)

[guardrex]

For cross-ref, here's where the decision was made :point_right: https://github.com/aspnet/Docs/issues/3076#issuecomment-294238613

[CESARDELATORRE]

Right, but Daniel is referring there specifically to the simple walkthroughs: "These tutorials are simple enough that I think implementing a repository is overkill. I'm in favor of removing it. Feel free to link to content that guides people to the more robust patterns though.".
I also agree on that.
However, a very different thing is to say "please consider not using repository pattern at all". I don't agree on that for the reasons and Application Architecture references I mentioned above.