This talk is put together well. So congrats on that! I would like to highlight some concerns though. The main one: If you start building a repository and then realize. "Oh 80% of my implementations concern crud. Why not make this generic" then you essentially misunderstood the repository pattern. The repository pattern only provides value as an abstraction if its implementation is very concrete. So allowing expressions for querying, is a leaky abstraction. It gets even worse, because what you build with EfRepository is nothing really else then what DbSet is. So you didn't really abstract anything. The minimum necessary would be to rewrite expressions so that you can get away from using EF.Functions.Foo(...) in expressions. But why would you do that? That is already what EF is for in the first place. So the whole idea of abstracting away from EF is just unnecessary complexity. Delete. Specs, are an interesting concept. I like the idea of moving specific queries into its own classes. The question here is what is the goal, the specs them self should not be effected by dependency injection ever, as you create them with the constructor, They cant even use anything else then expressions, so even if you had multiple per file you would not have dependency creep on the encapsulating class as that is out of scope of specs directly. So what is a spec essentially? I would argue it is nothing more then an extension method on IRepository, even simpler, on IQueryable. So essentially all of this is not needed, if you make sure that IQueryable is / Expression are not exposed from your repositories, which is actually what the repository pattern is all about. This is just a very fancy and complex approach of hiding this flaw. I hear you say: "But, 80% of my repositories, need this CRUD based functionality". Yes but that should be a choice then for those cases. Build a dedicated repository for crud operations, that can be generic even. Just don't make it the base for every other repository.
EF can delete without fetching the entity first. You can either do a new instance and assign the ID or from NET7 you have ExecuteDeleteAsync. As for leaking IQueryAble I'm split. When doing a REPR architecture I want to isolate my query with that request, so that I don't risk breaking other endpoints when I need to modify one of them.
This talk is put together well. So congrats on that!
I would like to highlight some concerns though. The main one:
If you start building a repository and then realize. "Oh 80% of my implementations concern crud. Why not make this generic" then you essentially misunderstood the repository pattern. The repository pattern only provides value as an abstraction if its implementation is very concrete.
So allowing expressions for querying, is a leaky abstraction.
It gets even worse, because what you build with EfRepository is nothing really else then what DbSet is. So you didn't really abstract anything. The minimum necessary would be to rewrite expressions so that you can get away from using EF.Functions.Foo(...) in expressions. But why would you do that? That is already what EF is for in the first place. So the whole idea of abstracting away from EF is just unnecessary complexity. Delete.
Specs, are an interesting concept. I like the idea of moving specific queries into its own classes. The question here is what is the goal, the specs them self should not be effected by dependency injection ever, as you create them with the constructor, They cant even use anything else then expressions, so even if you had multiple per file you would not have dependency creep on the encapsulating class as that is out of scope of specs directly. So what is a spec essentially?
I would argue it is nothing more then an extension method on IRepository, even simpler, on IQueryable.
So essentially all of this is not needed, if you make sure that IQueryable is / Expression are not exposed from your repositories, which is actually what the repository pattern is all about. This is just a very fancy and complex approach of hiding this flaw.
I hear you say: "But, 80% of my repositories, need this CRUD based functionality". Yes but that should be a choice then for those cases. Build a dedicated repository for crud operations, that can be generic even. Just don't make it the base for every other repository.
EF can delete without fetching the entity first. You can either do a new instance and assign the ID or from NET7 you have ExecuteDeleteAsync.
As for leaking IQueryAble I'm split. When doing a REPR architecture I want to isolate my query with that request, so that I don't risk breaking other endpoints when I need to modify one of them.