7 ms·

Agreed. Fortunately the main documentation now shows that this is an anti pattern since EF dbcontext is already a repository pattern and implements unit-of-work

Agreed. Fortunately the main documentation now shows that this is an anti pattern since EF dbcontext is already a repository pattern and implements unit-of-work semantics.

NicoJuicy 5y ago
I wanted to say exactly this.
DeathArrow 5y ago
Well, please explain to me how can I switch the app from using Postgres to Redis or Cassandra with ease if I am not using something like a repository pattern? It's true, EF abstracts the database away by not requiring you to write SQL but EF is only usable with some SQL databases. So, having another abstraction layer might not be a bad idea.
- javcasas 5y ago
  Yup, because we devs switch databases every week. That's the real reason why all projects are late: we are so busy switching databases all the time we don't have time for writing code!
- kingmotley 5y ago
  dotnet add package EfCore.Cassandra. Then in startup.cs or program.cs, add this to your services: optionsBuilder.UseCassandra("Contact Points=127.0.0.1;", opt => { opt.MigrationsHistoryTable(HistoryRepository.DefaultTableName, "<schema name>"); }); See more here: https://efcorecassandra.readthedocs.io/en/latest/intro/getting-started-with-efcorecassandra.html https://efcorecassandra.readthedocs.io/en/latest/intro/getti...
  - DeathArrow 5y ago
    Well, that's a new one. I didn't know there's an EF provider for Cassandra. Thanks for the update. :)
- manigandham 5y ago
  > "switch the app from using Postgres to Redis or Cassandra with ease" You can't. There is no such thing as switching databases "with ease" for any serious application. Postgres, Redis and Cassandra are all very different databases and it doesn't make sense to switch between them; unless your app is small and still experimental so the changes are trivial, or so large that it's a major project with very specific needs that requires far more work than a repository would solve. But if you really want to, Entity Framework already has multiple providers including non-relational databases like Cassandra. Anyone can write a provider and there are many 3rd-party libraries for whatever data source you want. > "having another abstraction layer might not be a bad idea." It's a terrible idea. It's such an exceedingly rare situation that you're wasting a lot of upfront work for something that'll never be used. Also .NET has a fantastic data system with LINQ which is built around `IQueryable` and provides powerful query modeling that can be incrementally and dynamically changed before its pushed down to the datasource. It's what makes EF so good and why repository patterns cause so many problems by breaking this interface for no productive reason. You can also use extension methods on the `DbContext` to extract complex queries or large operations to a single method. Now all that being said, there are times where you can have an abstraction/interface to your data sources if they're very complex or spread across multiple databases or have other processing needs. But at that point you actually need it, instead of just doing it as a "pattern".

Agreed. Fortunately the main documentation now shows that this is an anti pattern since EF dbcontext is already a repository pattern and implements unit-of-work semantics.

NicoJuicy 5y ago

I wanted to say exactly this.

DeathArrow 5y ago

Well, please explain to me how can I switch the app from using Postgres to Redis or Cassandra with ease if I am not using something like a repository pattern? It's true, EF abstracts the database away by not requiring you to write SQL but EF is only usable with some SQL databases. So, having another abstraction layer might not be a bad idea.

javcasas 5y ago
Yup, because we devs switch databases every week. That's the real reason why all projects are late: we are so busy switching databases all the time we don't have time for writing code!
kingmotley 5y ago
dotnet add package EfCore.Cassandra. Then in startup.cs or program.cs, add this to your services: optionsBuilder.UseCassandra("Contact Points=127.0.0.1;", opt => { opt.MigrationsHistoryTable(HistoryRepository.DefaultTableName, "<schema name>"); }); See more here: https://efcorecassandra.readthedocs.io/en/latest/intro/getting-started-with-efcorecassandra.html https://efcorecassandra.readthedocs.io/en/latest/intro/getti...
- DeathArrow 5y ago
  Well, that's a new one. I didn't know there's an EF provider for Cassandra. Thanks for the update. :)
manigandham 5y ago
> "switch the app from using Postgres to Redis or Cassandra with ease" You can't. There is no such thing as switching databases "with ease" for any serious application. Postgres, Redis and Cassandra are all very different databases and it doesn't make sense to switch between them; unless your app is small and still experimental so the changes are trivial, or so large that it's a major project with very specific needs that requires far more work than a repository would solve. But if you really want to, Entity Framework already has multiple providers including non-relational databases like Cassandra. Anyone can write a provider and there are many 3rd-party libraries for whatever data source you want. > "having another abstraction layer might not be a bad idea." It's a terrible idea. It's such an exceedingly rare situation that you're wasting a lot of upfront work for something that'll never be used. Also .NET has a fantastic data system with LINQ which is built around `IQueryable` and provides powerful query modeling that can be incrementally and dynamically changed before its pushed down to the datasource. It's what makes EF so good and why repository patterns cause so many problems by breaking this interface for no productive reason. You can also use extension methods on the `DbContext` to extract complex queries or large operations to a single method. Now all that being said, there are times where you can have an abstraction/interface to your data sources if they're very complex or spread across multiple databases or have other processing needs. But at that point you actually need it, instead of just doing it as a "pattern".