How Entity Framework Tries to Copy Dapper in .NET 8

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.

Hi Nick, did you try a benchmark using compiled query in EF8. Thanks!

No matter what , I think Dapper is still faster.

The FormattableString is similar to Serilog string format. Is this correct?

"Hello, everybody! I'm Naked" - I hear it all the time..

Before LINQ and Expressions Trees we used strings. I dont want to return to that practices

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.

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

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

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

nhibernate is better anyway ....

EF all the way

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?

Hi Nick,
Thanks for this Awesome video :)
Is there any discount coupon code for purchasing course from your website?

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.

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.

DbSet property is not required in your DbContext. If you just want IQueryable<T> you can use the Set<T> function of your DbContext

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.

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

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."

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!

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.

Does EF 8 needs .NET 8?

Thanks Nick. It was amazing and useful.
So we can use ef core instead of dapper in this senario👍

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.

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.

I thought it wasn't called 'Core' anymore?

Hi Nick, What do you think of RepoDb?

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.

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 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.

Happy 30th birthday Nick!

in EF you can map query to objects like this: dbContext.Set<Model>().FromSqlRaw("select * ...") but you need to have DbSet<Mode> added, you also can ignore this table from creating in DB.

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.

"Good is often good enough"

1st