How Entity Framework Tries to Copy Dapper in .NET 8
Vložit
- čas přidán 12. 04. 2023
- Check out my courses: dometrain.com
Become a Patreon and get source code access: / nickchapsas
Hello, everybody, I'm Nick, and in this video, I will show you a new Entity Framework Core 8 feature that is aiming to replace Dapper. We will take a look at what it is, how it works, and why it won't be replacing Dapper in your codebase, at least for now.
Other EF Core vs Dapper videos:
• Entity Framework Core ...
• Making Entity Framewor...
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: bit.ly/ChapsasGitHub
Follow me on Twitter: bit.ly/ChapsasTwitter
Connect on LinkedIn: bit.ly/ChapsasLinkedIn
Keep coding merch: keepcoding.shop
#csharp #dotnet
I accidentally cut the part explaining it but the reason why I am testing FormattableString later in the video is to see if the generated templates are interned/optimized to prevent future allocations.
I presume it takes an interpolated string handler, so caching the formattable string should be possible, I think.. don't know if they do though.
As for EF vs Dapper, I'd use both. If it's not going back into the DB there's no reason to use change tracking etc.
I believe the EF can never predict how to not screw up indexes. Dapper keeps it simple.
Happy 30th birthday Nick!
DbSet property is not required in your DbContext. If you just want IQueryable you can use the Set function of your DbContext
Dapper and EF Core have simply different use cases. Use dapper when performance is critical and use EF Core when it is not and you rather have the better development experience of Linq-to-SQL.
For me the best thing about dapper is I can fetch all potentially relevant data at the beginning of a large workflow and only wait on it right before I actually need it.
Although you can technically do this with EF, most MS shops inject a db context into the repo class and use only 1 dbcontext per repo instance, which prevents you from using concurrent queries like you always can in dapper
Thanks for all the great informative content Nick! Been a great help in my professioinal career so far. Would you be able to do a video on why yo prefer not to use stored procedures? I don't have a dog in (what is apparently) this fight, I just have seen(and had to work with) stored procedures during my career and wanted more insight on thefrom someone who has more architectural/Devops knowledge than I do!
Thanks again!
most devs are middle-tier-centric so that shapes their view of how to code systems. SQL in the middle tier is natural to them as if it was building a json payload or querystring to fetch data from a 3rd party API. And that works, but there was 1 instance I worked where sprocs were heavily used. That was a company that required high security, their architecture was sprocs only for DB access, the DBs were configured to only have execute permissions - no read access at all. So all our queries had to be written in a sproc. It worked really well, once you realised what was needed it was easy to code in that pattern.
I think most people hate the idea of sprocs from ancient times using mainframes where a lot of business logic was put in the DB as it did everything, or Oracle forms type programming. But those days can't really be called SQL programming like we're used to today. I think the mindset still lingers though.
Dapper in its simplicity is unbeatable...
Hi Nick,
Thanks for this Awesome video :)
Is there any discount coupon code for purchasing course from your website?
The constructor injecting dbcontexts into repos is also how EF is presented in tutorials so I can’t blame the MS shops, they are just following instructions. It’s the safest way to use EF as well, so I don’t blame them either.
However I think they should add an additional AsConcurrentNoTracking fluent option, which would effectively use a separate new context behind the scenes instead of the repo scoped context.
The we could see dramatic performance improvements on complex workflow data fetching speeds
Hi Nick, did you try a benchmark using compiled query in EF8. Thanks!
I'm kind of curious to see how the `FormattableString` would handle an nvarchar param. I can't imagine it would put quotes around it? But a parameterized query certainly would.
in EF you can map query to objects like this: dbContext.Set().FromSqlRaw("select * ...") but you need to have DbSet added, you also can ignore this table from creating in DB.
Thats not what we are testing
Hi Nick first thanks for your job. I never used EF, I feel more comfortable working with Dapper and stored procedures. It give a way to make some changes without even touch my code
But you end up touching code the same way, just in a different language and thing where it runs on, and now you have 2 code bases to take care instead of 1
Nice that you made another video to compare both! What's your guess on why Dapper is still so much faster? What's happening behind the scenes?
I will probably do a "dig deeper" stream
@@nickchapsas awesome 🔥
@@jogibear9988 I've love to see linq2db as well.
It doesn’t have to build an iqueryable expression tree and be everything to everyone… EF in many circles is kind of a joke really
@@chswin EF is only a "joke" in circles it never had intentions of being in. EF was never designed to be the fastest option out there
Hi Nick, What do you think of RepoDb?
Thanks for this video, but what I don't understand is that we have already the FromSqlRaw, that method in EF 6 does what SqlQuery in EF8.
I would imagine the the EF8 has to create a parameterised version of the SQL string, then create a command with parameters. Whereas in Dapper you have done the work of creating the the parameterised SQL, already. Dapper can use the SQL constant you have supplied as is.
As you can see later in the video the string for the query has no visible impact on speed and only a minor one on memory
@@nickchapsas Are you sure? In dapper you would use "...YearOfRelease = @YearOfRelease" whereas even in your SQLQueryRaw example you as using "...YearOfRelease = {0}". This implies that SqlQueryRaw has more string work to do prepare the Sql String to be passed to the underlying engine. Am I missing something?
Dapper does not do any "String.Format" things. It doesn't read the provided SQL at all. It passes SQL and parameters as they are, down to db provider.
On the other hand, EF methods FromSql and FromSqlInterpolated first have to change "SELECT * FROM Movies WHERE Id={0} LIMIT 1" into something like "SELECT * FROM Movies WHERE Id=@p01 LIMIT 1" and prepare a parameter for db. And here I have a small warning about FromSqlRaw, because this one doesn't do this and hence is vulnerable to SQL injection attacks, if improperly used.
String interpulation has already been fixed in the compilation stage, you don’t need to turn your strings into templates anymore the compiler does that now
The FormattableString is similar to Serilog string format. Is this correct?
I need to ask... What is the SQLLite viewer extension you are using?
Thanks Nick. It was amazing and useful.
So we can use ef core instead of dapper in this senario👍
It seems there is a big difference between .FromSql() which uses sql parameters and .FromSqlRaw() which uses string interpolation. Why not test both of those methods as well?
"Good is often good enough"
You haven't even watched the video yet 😂
@@nickchapsas I swear I did after commenting. Fully from start to end ♥
@@nickchapsas I have and I suspect @Uwe Keim is right 😉
I am a bit disappointed that EF is positioned as a competitor to Dapper. Marketing a feature-rich ORM as a tool for ETL seems to me not the best idea. Its strongest part should be mapping DB structures to complex domain objects and change tracking (if needed), that is I'd put more emphasis on DDD-like things.
What they are aiming to do is to provide equal functionality so you dont need to bring in and support more packages just to write those 2-3 queries.
It would be nice if EF got better in areas where Dapper excels.
It’s not really a competitor. They just wanna add the one feature that you would have to bring in dapper because EF didn’t support it but since it’s the same functionality it’s good to compare them
@@fusedqyou Competition is good, but I think EF and Dapper target slightly different areas. If EF can deliver same features as Dapper with same or better performance, it's ofc good.
@@nickchapsas It's kind of not tho. If I compare a bus to a sportscar the sportscar will always win even if you just pick out the engine of both. But the sportscar will lose when comparing how many people fit inside. While I like your Benchmark videos they are always lacking of the greater context of software developing that is the time developers might need to go through code, maintain. Your conclusion was just: Use Dapper not EF Core because this Benchmark speed in this scenario...
What you might want is a fair example of code like: create the data, get the data, manipulate the data and update it on the db in terms of speed and lines of code written and how many parts needs to be touched when for example refactoring is needed.
For me is more interesting to call SP, for both update and request scenarios. And do it in scope of one transaction, Dapper is very good with it.
hum - I wonder if the perf improved with the release of the .net 8
ef 8.0.3 doesn't contain SqlQuery()? in the context.Database, why?
Before LINQ and Expressions Trees we used strings. I dont want to return to that practices
While this is all definitely interesting, it's worth noting that this sort of thing is hardly ever relevant in real-world applications.
The actual bottleneck of your app, performance-wise, is almost invariably going to be the queries themselves and the time it takes for the database engine to actually execute them and return the results.
Obsessing over a few microseconds here and there isn't very productive. The DX benefits you get out of an elegant ORM like EF normally far outweigh those relatively insignficiant performance gains you might get by opting for a lower-level tool like Dapper, at least in most scenarios.
So, take these benchmarks and so on with a grain of salt. Although they're interesting, this type of thing shouldn't really be what ultimately informs your decision on which tool you should be using for your project.
Remember: "Premature optimization is the root of all evil."
totally agree! if you ACTUALLY need to improve performance for such a query, your time would be much better spent implementing caching, to avoid the expensive DB round-trip.
💯 Agree with this, in the past 6 or 7 yrs of working with enterprise level applications I haven’t seen anything that used Dapper, all of them used EF core all throughout and its because the benefits far outweighs the performance gains you get with Dapper, as long as you do it correctly and consistently, even though there is some microseconds or even a second of perf gain from Dapper, the speed at which you can get things out the door and in the hands of the customer is far more critical.
@@judeisraelialquiza6706 Stack overflow
That is entirely context dependent, the bit about premature optimization when taken to the root of all evil in a faux jest, seems to be very commonly used as an excuse to Never optimize and opt for coder preferences over applicability for tooling.
The professionalism of the programmer is measured in how, when and at what level should optimization be done, when it's done as an afterthought it's usually too late to get the easiest gains that would've been very easy to work around earlier had you known about it at the time!
@@RiversJexactly
Very unintuitive result.
Nick, you should dig dipper, plz :)
The only guess (without actual doc reading/debugging) is that this query is not so "detached" from the db context.
"Hello, everybody! I'm Naked" - I hear it all the time..
Does EF 8 needs .NET 8?
They generally target the latest LTS version of .NET, so *probably*, but don't hold me to that.. EF 6 and 7 targeted .NET 6, soo...
I thought it wasn't called 'Core' anymore?
Yeah but most people don’t know that yet so I added it for SEO purposes
I still can't ever see myself using an ORM such as EF, but nice to see they're getting some of the features that it's missing.
Do you also put all business logic in stored procedures?
@@PelFox None at all
@@PelFox nobody does that anymore. And they only did that back in the days with systems that were built with thin clients in mind.
EF all the way
As far as I am concerned EF has never really been fit for purpose, it is overweight, slow , and very limited.
It also involves a non-model first approach by forcing you to manually generate migrations using command line when using model-first. Then manually tell it to update the db. From my POV that is a DB-first approach that just happens to work a bit differently.
It also requires a lot of code for a simple system.
Give me NoSQL like VelocityDB or Realm any day, but if you have to use SQL (and in some cases SQL will be the better choice) then a lightweight ORM or something like dapper is a much better choice than EF.
I've written several model/DbContext in C# for an existing DB without tools, and there *are* tools that can help with it. I didn't find it that difficult, but the DB only had 4-5 tables I was interested in. Last time was to convert the link visitation history from Firefox to Chrome (Vivaldi, really, but it's basically the same).
Using EF Core with raw SQL makes no sense as it kills almost all ORM benefits. Too bad they are working on this rather than improving LINQ query translator, adding window function support to it etc.
No matter what , I think Dapper is still faster.
1st
nhibernate is better anyway ....