Overall good approach, the one thing I don't like here is that we end up with many many specification classes. I think we have to make it more "composition over inheritance"
It's hard to see in these examples, but you can define and reuse specifications. Imagine a particular query is used in several places and needs to be consistent. Also, you can actually unit test the specifications in isolation of your database. If that's useful to you.
This architecture benefits me well as I can easily create a query function in a single location that can be used by every interface and services of my API as I add more entities to it. It's like a generic repository pattern: single location, easy to read, maintain, and debug. All querying functions are in a single location. One function added to the Specification.cs will be available instantly to the entire interface and services that is mapped with the Specification object.
Hi Patrick, great stuff. I am really glad I came across your channel, I love the way you teach, very simple and clear. I just have two questions: So if I understand correctly now, basically instead of having a monster repository class you will have tons of smaller classes implementing each and every possible permutation of the query? And secondly, my old brain always likes to re-use code, so would it be an anti-pattern to parameterize the specifications with the filter and include and order by so you can get the filters etc. from a view passing into the controller? Any thoughts on this, or are there other patterns that could solve that problem better. Thanks again for a really good tutorial, looking forward going through all your stuff, and really interested in everything .net 8.
Great stuff! I always appreciate your videos… Just curious - is there a reason why you didn’t turn the SpecificationQueryBuilder into an extension method (with just an extra ‘this’ keyword)? Wouldn’t that increase the readability a bit more? You would be able to write context.QueryWithSpecification(Expression exp)
Patrick, great video indeed this is! Now, how could we pass the where clause value ("RPG") to the controller (also the includes and ordeby), so I want to get this and not a static specification class; GET /api/Game/{genre}
My thoughts exactly. It seems quite wasteful to have to write specifications per each ‘type’ that could possibly be queried and also by parameter using, you kind of follow the OCP principle by making it more flexible. Excellent video though!
object' does not contain a definition for 'Aggregate' and no accessible extension method 'Aggregate' accepting a first argument of type 'object' could be found (are you missing a using directive or an assembly reference? how to remove this error
Thanks, bro what if I need more than one condition in the where clause, for example, I need Employee where the name is "Patrick" and IsPresent. How to implement that here
Hey. You create instance of every Specification for each API request and these instances don't take parameters. Is it better to make them static or create them once at the beginning?
“I will not include everything here now so you don’t get scared”… yeah that ship had sailed lol
Overall good approach, the one thing I don't like here is that we end up with many many specification classes. I think we have to make it more "composition over inheritance"
Thanks for the videos but I think with this one we are entering into the over engineering territory .
Yeah i agree, lets build more abstraction between repository and database just seems wrong
Your mom is entering into the over engineering territory
This looks like CQRS with additional steps.
I didn't understand what's the benefit
It's hard to see in these examples, but you can define and reuse specifications. Imagine a particular query is used in several places and needs to be consistent. Also, you can actually unit test the specifications in isolation of your database. If that's useful to you.
This architecture benefits me well as I can easily create a query function in a single location that can be used by every interface and services of my API as I add more entities to it. It's like a generic repository pattern: single location, easy to read, maintain, and debug. All querying functions are in a single location. One function added to the Specification.cs will be available instantly to the entire interface and services that is mapped with the Specification object.
*Superb!, I appreciate the effort you put into making these videos*
Hi Patrick, great stuff. I am really glad I came across your channel, I love the way you teach, very simple and clear. I just have two questions: So if I understand correctly now, basically instead of having a monster repository class you will have tons of smaller classes implementing each and every possible permutation of the query? And secondly, my old brain always likes to re-use code, so would it be an anti-pattern to parameterize the specifications with the filter and include and order by so you can get the filters etc. from a view passing into the controller? Any thoughts on this, or are there other patterns that could solve that problem better. Thanks again for a really good tutorial, looking forward going through all your stuff, and really interested in everything .net 8.
Great stuff! I always appreciate your videos… Just curious - is there a reason why you didn’t turn the SpecificationQueryBuilder into an extension method (with just an extra ‘this’ keyword)? Wouldn’t that increase the readability a bit more? You would be able to write context.QueryWithSpecification(Expression exp)
I just woke up to this, so sweet stuff. Patrick isn’t this the query object pattern described by Fowler in PoEE?
Hi, can you please make a video on blazor with google auth deployed to azure? I know you have one already but that is only working locally.
Includes will never be null right?
Show later how to combine multiple specifications
Patrick, great video indeed this is! Now, how could we pass the where clause value ("RPG") to the controller (also the includes and ordeby), so I want to get this and not a static specification class;
GET /api/Game/{genre}
My thoughts exactly. It seems quite wasteful to have to write specifications per each ‘type’ that could possibly be queried and also by parameter using, you kind of follow the OCP principle by making it more flexible.
Excellent video though!
object' does not contain a definition for 'Aggregate' and no accessible extension method 'Aggregate' accepting a first argument of type 'object' could be found (are you missing a using directive or an assembly reference? how to remove this error
Thanks, bro what if I need more than one condition in the where clause, for example, I need Employee where the name is "Patrick" and IsPresent. How to implement that here
Hey. You create instance of every Specification for each API request and these instances don't take parameters.
Is it better to make them static or create them once at the beginning?
Hi Patrick, I was wondering how will you handle the ThenInclude in the expression?
@PatrickGod don't answer, it seems ....
Excuse me, what is here from .Net 8?
nothing pretty much, same can be achieved with net 5, dunno maybe with previous versions too
this is too much, Kiss