The source code that Brendan used to create code samples for this talk is here ➡ github.com/brendan-ssw/Northwind-EFCore3 Camilla Rosa SSW TV | Videos for developers, by developers ssw.com.au
Great stuff. Anyone who likes this should also watch the video from Jason Taylor on NDC Sydney 2019 where he demo's a similar approach using auto-mapper. The only thing I do not like is ApplyFilters() as a method to apply all filters at once. A cleaner way would be to have methods that return a queryble per filter and apply those after one another.
I personally use repositories interface above EF core layer because in early stages of products I prefer to use rather file system over database. Also it's easier to replace EF Core to another approch for managing data
It helps having information grouped together because it increases understanding and clarity before stacking layers of data on top a foundation of confusion. Just like in classroom where teacher makes sure everyone understands before moving on, this is helpful for some us that get lost along the way.
In the project I worked, the Repository pattern layer didn't grew up to become business logic; there was another layer, we called it Services, and that layer had some fancy logic and [UnitOfWork] attributes marked methods, which could call and use several methods from different Repositories, and all the sql requests would be done in one transaction.
Sounds like a great solution. I've done a very similar thing and called it the "Business Logic" layer. All works great as long as you keep the right code in the right layers. A good rule of thumb here is that as soon as two repositories are involved, that's when it need to go into another layer with some form of unit-of-work. Avoid makling one repository call another repository - I've never seen this end well!
That's exactly what Ive constructed in the project I'm in now. We need complex logics to represent domain rules and we want to consider transactional contexts between it. So domain service contains unit of work to ne injected as default. It just ended up like this form naturally.
Very informative video on under the hood mechanics of EF. I'm a great fun of EF Code First model. Could you kindly do a video on how to write and use SQL Server stored procedures using EF code First. Also how to use EF with advanced data types in SQL Server ie Spatial and JSON data types
DbContext + vertical slicing (as opposed to CQRS, which is most often a misnomer when people discuss their use of MediatR) indeed can be a sufficient replacement for the classical repository pattern, because the vertical slices (with e.g. request handlers via MediatR*) are a good place to store query logic that pertains to individual operations. But there are still some pretty general cross-cutting-like concerns that make the repositories (+ UoW, because saving in a repository is ugh) a useful abstraction. For example defining default queries, defining includes for different queries, and adding paging/filtering/ordering logic. Plus I think it also has some limited inherent value in itself that EF Core is abstracted, and your application core has zero direct references to it (provided that you also avoid using DataAnnotation attributes on domain models; although those aren't strictly EFCore-specific). *One of my pet peeves being that MediatR is also a misnomer, because what it does is essentially commanding, i.e. encapsulating operations/requests in commands and corresponding handlers, with a questionable service locator on top; instead of 'mediating' in the classical Mediator design pattern sense. It's still a great piece of software, of course. Thanks for the great talk btw! Definitely one of the most informative and tightly packed talks I've seen on the subject.
at 30:50 setting the state explicitly to modified is to show that the entity can be passed to the method without being tracked (it can be retrieved with AsNoTracking) and it will be saved to the db regardless.
yes, Jason's Northwind Traders project is now pretty much the base of any talk I do. And this post (www.codingflow.net/building-single-page-applications-on-asp-net-core-2-2/) has been my "file->newProject" walkthrough on a couple of projects recently - saving a lot of time!
Very good talk, very useful ! thank you It was too quick for me so I reduce the speed of the video to 0.75, then it was even more interesting :) ... it sounds like a drunk person :)
At 5:00 that schema is typically a one-to-many relationship. :P Since you can insert multiple skills for the same PersonId foreign key (unless we explicitly add a Unique constraint besides the foreign key constraint). Strict one-to-one (well, actually one-to-zero-or-one, because it's technically impossible to enforce 1-to-1) would be using the PersonId as the primary key in the Skills table, which would constrain us to store only a single skill per PersonId. I know I'm nitpicking. :D Edit: Ah okay, 30 seconds later you mention it. That's why I should always watch the whole video before commenting. Which I never do of course.
One big benefit to separating out commands vs queries is also the opportunity to cache the responses from queries. serving shared lookup data from cache will always beat any db based lookup.
I just don’t understand what is the benefit of having the INorthWindDbContext over the top of the DbContext class....not sure what the author wanted to achieve with it...
I download your repo and try to run Add-Migration, it throws this error Your target project 'Northwind.EF.WebApi' doesn't match your migrations assembly 'Northwind.EF.Persistence.MSSQL'. Either change your target project or change your migrations assembly. Change your migrations assembly by using DbContextOptionsBuilder. E.g. options.UseSqlServer(connection, b => b.MigrationsAssembly("Northwind.EF.WebApi")). By default, the migrations assembly is the assembly containing the DbContext. Change your target project to the migrations project by using the Package Manager Console's Default project drop-down list, or by executing "dotnet ef" from the directory containing the migrations project. Could you please show me details how you run your migrations?
@@nghiemhoang1916 Yes, my proof-of-concept for setting up a project against multiple databases does make the whole migrations process much harder! I've also added the Northwind.EF.Persistence.Tools project - this is a small console project that can act as the startup assembly for running migrations. The migrations systen needs to start against a target framework - can't bootstrap with a netstandard project.
After 20 years of using ORM's, I can say that they suck for performance and maintainability. ADO.net abstracted by a repository pattern is faster, easier to manage and doesn't break every 5 minutes on package updates (as in EF).
Bullshit, after 15 years of using ORMs, I can say that they have come a long way, and EF Core is awesome right now. Performance is fine for most apps, and every other aspect is better than raw ADO.NET.
EF is garbage because you cant write raw sql if sql query doesn't return ALL fields of table. if you have 20 columns and you only one to select 1 column -you cant... EF is created to be slow and big
Woo, look how clean my ORM code is, it's amazing. Now let's deploy it into production and watch everything slowly grind to a halt as the bullcrap ORM sql written by clueless .net coders drags my poor database server to its knees 😂😂😂
If your coders are clueless, they will write bad queries anyway, be it LINQ or SQL. At least with LINQ there is less chance for sql injection vulnerabilities. Hire good coders and their queries will be good, no matter ORM or not.
EF is GARBAGE!!! if key is LONG you CANT use this XXX.Find(1)...will get error..because you must use XXX.Find((long)1). NEVER ever seen such problem when you cant use int in LONG property.
The source code that Brendan used to create code samples for this talk is here ➡ github.com/brendan-ssw/Northwind-EFCore3
Camilla Rosa
SSW TV | Videos for developers, by developers
ssw.com.au
fsdf4
Just watched this now and I have to say that as I'm just learning EF core it's one of the best talks I have every seen on the topic. Thanks SSW.
Nailing it every single time Brendan! Love the energy level and focus you keep even when interrupted. Congrats, keep the great work!
Clean architecture at 32:28
Best line: "The secret-sauce of spaghetti code is dependencies".
Could we maybe call it dependency pomodoro or dependency fettuccine?
Great stuff. Anyone who likes this should also watch the video from Jason Taylor on NDC Sydney 2019 where he demo's a similar approach using auto-mapper. The only thing I do not like is ApplyFilters() as a method to apply all filters at once. A cleaner way would be to have methods that return a queryble per filter and apply those after one another.
I've been using repo pattern for quite a while, 1st time I hear about CQRS... seems really good.
Great presentation, Brendan!
Outstanding presentation! Thank you so much for sharing your thoughts.
I personally use repositories interface above EF core layer because in early stages of products I prefer to use rather file system over database. Also it's easier to replace EF Core to another approch for managing data
That is just stupid.
Great presentation. I think it would be nicer for the speaker if there were question segments, so there is no interruptions to the presentation flow.
It helps having information grouped together because it increases understanding and clarity before stacking layers of data on top a foundation of confusion. Just like in classroom where teacher makes sure everyone understands before moving on, this is helpful for some us that get lost along the way.
In the project I worked, the Repository pattern layer didn't grew up to become business logic; there was another layer, we called it Services, and that layer had some fancy logic and [UnitOfWork] attributes marked methods, which could call and use several methods from different Repositories, and all the sql requests would be done in one transaction.
Sounds like a great solution. I've done a very similar thing and called it the "Business Logic" layer.
All works great as long as you keep the right code in the right layers. A good rule of thumb here is that as soon as two repositories are involved, that's when it need to go into another layer with some form of unit-of-work. Avoid makling one repository call another repository - I've never seen this end well!
That's exactly what Ive constructed in the project I'm in now. We need complex logics to represent domain rules and we want to consider transactional contexts between it. So domain service contains unit of work to ne injected as default. It just ended up like this form naturally.
This is pure gold!!! Thank you!
Very informative video on under the hood mechanics of EF.
I'm a great fun of EF Code First model.
Could you kindly do a video on how to write and use SQL Server stored procedures using EF code First.
Also how to use EF with advanced data types in SQL Server ie Spatial and JSON data types
1:12:26 *FromSqlRaw* : Here you can pass the name of Stored procedure along with the parameters.
DbContext + vertical slicing (as opposed to CQRS, which is most often a misnomer when people discuss their use of MediatR) indeed can be a sufficient replacement for the classical repository pattern, because the vertical slices (with e.g. request handlers via MediatR*) are a good place to store query logic that pertains to individual operations. But there are still some pretty general cross-cutting-like concerns that make the repositories (+ UoW, because saving in a repository is ugh) a useful abstraction. For example defining default queries, defining includes for different queries, and adding paging/filtering/ordering logic. Plus I think it also has some limited inherent value in itself that EF Core is abstracted, and your application core has zero direct references to it (provided that you also avoid using DataAnnotation attributes on domain models; although those aren't strictly EFCore-specific).
*One of my pet peeves being that MediatR is also a misnomer, because what it does is essentially commanding, i.e. encapsulating operations/requests in commands and corresponding handlers, with a questionable service locator on top; instead of 'mediating' in the classical Mediator design pattern sense. It's still a great piece of software, of course.
Thanks for the great talk btw! Definitely one of the most informative and tightly packed talks I've seen on the subject.
at 30:50 setting the state explicitly to modified is to show that the entity can be passed to the method without being tracked (it can be retrieved with AsNoTracking) and it will be saved to the db regardless.
Thank you for this!
I love that project of his.
yes, Jason's Northwind Traders project is now pretty much the base of any talk I do. And this post (www.codingflow.net/building-single-page-applications-on-asp-net-core-2-2/) has been my "file->newProject" walkthrough on a couple of projects recently - saving a lot of time!
Very good talk, very useful ! thank you
It was too quick for me so I reduce the speed of the video to 0.75, then it was even more interesting :)
... it sounds like a drunk person :)
0.5 speed makes the voice even more funny :D
That's very bad for productivity, I usually do the opposite and speed up videos.
At 5:00 that schema is typically a one-to-many relationship. :P Since you can insert multiple skills for the same PersonId foreign key (unless we explicitly add a Unique constraint besides the foreign key constraint). Strict one-to-one (well, actually one-to-zero-or-one, because it's technically impossible to enforce 1-to-1) would be using the PersonId as the primary key in the Skills table, which would constrain us to store only a single skill per PersonId. I know I'm nitpicking. :D
Edit: Ah okay, 30 seconds later you mention it. That's why I should always watch the whole video before commenting. Which I never do of course.
Great presentation. I will use it in my project.
how is it clean when your application layer depends on persistence layer (there is reference to EntityFrameworkCore)
yeah I definitely see shortcuts here.
and that's probably suitable for a very contained, small scoped service.
1:29:25 what is the name of the lib for BulkInsert ?
Problem with that approach is if u have allot of lookups lists being consumed thru one unit of work it be very performance hungry.
One big benefit to separating out commands vs queries is also the opportunity to cache the responses from queries. serving shared lookup data from cache will always beat any db based lookup.
Looks pretty cool. Where can I find the source code?
Hey Ryan, pretty sure you can find it here: github.com/brendan-ssw/Northwind-EFCore3
nHibernate for .NET was a mess. I don't know what you think was so great about it.
Did you mean new object, not new class at 9:55?
FYI, the source code is located... github.com/SSWConsulting/Northwind365
I just don’t understand what is the benefit of having the INorthWindDbContext over the top of the DbContext class....not sure what the author wanted to achieve with it...
I download your repo and try to run Add-Migration, it throws this error
Your target project 'Northwind.EF.WebApi' doesn't match your migrations assembly 'Northwind.EF.Persistence.MSSQL'. Either change your target project or change your migrations assembly.
Change your migrations assembly by using DbContextOptionsBuilder. E.g. options.UseSqlServer(connection, b => b.MigrationsAssembly("Northwind.EF.WebApi")). By default, the migrations assembly is the assembly containing the DbContext.
Change your target project to the migrations project by using the Package Manager Console's Default project drop-down list, or by executing "dotnet ef" from the directory containing the migrations project.
Could you please show me details how you run your migrations?
I found the root cause. I have to run with command Add-Migration -Project -StartupProject -Name
@@nghiemhoang1916 Yes, my proof-of-concept for setting up a project against multiple databases does make the whole migrations process much harder! I've also added the Northwind.EF.Persistence.Tools project - this is a small console project that can act as the startup assembly for running migrations. The migrations systen needs to start against a target framework - can't bootstrap with a netstandard project.
Wait a minute, this is more or less the same material from Jason more than a year ago.
Thank you 🙏 but please change your microphone!
the URL for the repo
github.com/brendan-ssw/Northwind-EFCore3
Hi Goncalo,
Thanks for getting in touch, how can we help?
I've added Brendan to the loop if it is related to his GitHub.
Penny
ssw.com.au
After 20 years of using ORM's, I can say that they suck for performance and maintainability.
ADO.net abstracted by a repository pattern is faster, easier to manage and doesn't break every 5 minutes on package updates (as in EF).
Bullshit, after 15 years of using ORMs, I can say that they have come a long way, and EF Core is awesome right now. Performance is fine for most apps, and every other aspect is better than raw ADO.NET.
@@Kefir0 Respect your view but, based on my observations, disagree.
Dapper is far far better than the EF Core. You will have a full control to solve the impediments.
EF is garbage because you cant write raw sql if sql query doesn't return ALL fields of table. if you have 20 columns and you only one to select 1 column -you cant... EF is created to be slow and big
"lightweight", hmm. :) I'd think something like Dapper is lightweight.
Woo, look how clean my ORM code is, it's amazing. Now let's deploy it into production and watch everything slowly grind to a halt as the bullcrap ORM sql written by clueless .net coders drags my poor database server to its knees 😂😂😂
Have fun in your misguided world.
So you are saying every SQL query you or anybody in your team has written is absolutely perfect and optimized?
If your coders are clueless, they will write bad queries anyway, be it LINQ or SQL. At least with LINQ there is less chance for sql injection vulnerabilities. Hire good coders and their queries will be good, no matter ORM or not.
@@Kefir0 while OP being provocative, I can concede that translating plain sql to EF Linq equivalent is sometimes not an easy task.
EF is GARBAGE!!! if key is LONG you CANT use this XXX.Find(1)...will get error..because you must use XXX.Find((long)1). NEVER ever seen such problem when you cant use int in LONG property.