Entity Framework Best Practices - Should EFCore Be Your Data Access of Choice?

[@jamesbest3347]

"If the way someone develops a C# application makes you angry, I suggest you reevaluate your priorities in life." LOL legend

[@IAmTimCorey]

lol thanks.

[@jamesbest3347]

@@IAmTimCorey Tim, I also wanted to say I agree with you 100% on your disposition towards Dapper. For smaller applications where you might have a single login that's connected to very minimal amount of user data I believe EntityFramework is a great tool because you don't need to know much about the DB as it's all handled with a model first approach. It's when your small application turns into a larger thing that you realize you wish you were managing this stuff yourself because the migrations start becoming a real hassle and performance can start to decrease. That said, does Dapper have a similar tooling to EF in that it will generate a migration or SQL script to create your DB from the model? Writing queries isn't really an issue for me, but I really do like the model first approach of EF. Thank you!

[@IAmTimCorey]

I haven't found one I liked yet and I'm considering writing one.

[@IAmTimCorey]

The problem with using EF for creating the database is all of the work you need to do to get it right. I recommend SQL Server Data Tools, which give you database source control and automated deployment but are more clear about what they are doing than EF: kzbin.info/www/bejne/n5unlHt9rd6ke5Y

[@JasonDias7]

@@IAmTimCorey yup, that's what we are using. But it forces you to work with Database First, not saying that it's bad. But, there is no good alternative if you want to go Code first

[@GreggBursey]

Man, there are hundreds of videos on “how to EF”, and that’s fine. But your walkthrough here that included not only that, but also the pitfalls, what could cause problems, and WHY those can be problems was extremely helpful. The section explaining the string fields like NVARCHAR(MAX) was very informative and helpful.

[@IAmTimCorey]

I am glad it was so helpful.

[@tchpowdog]

I agree with everything your saying here in regards to having to be experienced in order to use EF efficiently. However, everything you laid out is from a "code-first" perspective. I use EF in all my projects, but I don't use their migration and schema tooling. I use good-ole fashioned DB-first approach. I use SSMS as much as I use Visual Studio. Also, I only use EF for entity level CRUD operations and very basic queries. If I have ANY more-than-basic queries or data logic, I use SPs, Views, Functions, etc. - then I call those functions through EF. I wouldn't recommend using EF for a code-first approach, either. However, I wouldn't recommend code-first AT ALL. Personally, I despise the code-first approach - but I also appreciate the fact that it works for other people.

[@IAmTimCorey]

Yeah, I think the big takeaway is to be careful and know what you are doing really well. Code First, which is the method that is most often pushed, can be done well if you are careful but if you aren't, you can create a mess.

[@LiganPL2]

I have the same opinion as you. In my company it looks the same as you explained. We never used code-first model.

[@znk0r]

Curious to know a bit more about what makes you despise code first. We had a team discussion before starting a second code first project and we mostly agreed we liked the fact that devs could focus on what made sense in code and have the ability to refactor without having to create the schema updates themselves. Yes you have to handle the data updates and merging stuff between branches but we still felt it was worth it. It wasnt 100% unanimous so outside opinions are interesting.

[@tchpowdog]

@@znk0r I just like the database first mentality. I am a systems architect and I build web applications, pretty much only web. SQL and Oracle are incredibly powerful and I feel they are under-used with a code-first approach. I believe one's first intuition should be to place logic in the database via SPs, Functions, etc (of course this isn't always the right thing to do). Being database first also aligns with my system architecture philosophy, which is: Lightweight Web API that scales horizontally Heavy database that scales vertically Fast front-end framework (Angular or React) I understand there are trade-offs either way and a lot of it depends on the application. I guess the thought of a programmer creating a database without much knowledge of databases scares me, so I'd just assume not go there lol For example, I hired a brilliant programmer about two years ago and he has done a great job, but he never learned SQL or Oracle in school. That's scary to me. When you reach scale, you can put yourself way behind by running into severe performance issues if you don't know how databases work. But like I said, I do appreciate the fact that it works well for others.

[@timetorelax45]

@@tchpowdog I have similar background as yours and we used to despise database queries being programmed inefficiently in the application layer by people who seemed to not care too much about database design. So, we improved up on that by moving database related to sp and functions. Gave us so much more control and flexibility. Having said that, I recently started using code first ef core and I love that I have all my logic in one place, however I am careful with it and use it efficiently by keeping an eye on how things work under the hood. I agree it can go bad if done by people who know little or care less about databases.

[@MrCalletennis]

If you're to lazy to use your mouse :) 00:02 Consider EF Core for improved performance 02:23 Setting up the environment in Visual Studio 08:01 Utilize string for zip codes for flexibility in address modeling. 10:59 Setting up Entity Framework with SQL Server 16:51 Configuring Entity Framework Core for SQL Server 19:09 Setting up a local DB for Entity Framework usage 23:32 Setting up Entity Framework Core Tools for Package Manager Console 26:15 Separation of concerns can prevent major overhauls 31:09 Rollbacks in Entity Framework come with potential data loss risks 33:37 Database design considerations for EFCore 38:53 Understanding model snapshot in EFCore 41:28 Unicode takes up twice as much storage as ASCII 46:35 Storage space and memory allocation implications for nvarchar(max) columns 49:09 Column type impacts memory usage and performance in Entity Framework. 54:22 Understanding one-to-many relationship in Entity Framework 56:43 Modifying tables for better design 1:01:49 Memory usage becomes a limiting factor in production environment. 1:04:10 Modifications made to models for validation. 1:08:58 Roll back in Entity Framework affects schema, not data. 1:11:15 Best practices for using Entity Framework 1:16:25 Database data loading and insertion process explained 1:19:06 Utilizing X event profiler for diagnosing EF queries 1:24:27 Entity Framework efficiently uses 'select count star' to find number of rows in table. 1:27:04 Entity Framework batch inserts without creating a stored procedure 1:32:01 Entity Framework lacks database security 1:34:23 Use of SP_ExecuteSQL for efficiency improvement 1:39:21 Using Include to fetch related data efficiently 1:41:46 Understanding batch completion and memory information retrieval 1:46:45 Entity Framework handles one-to-many relationships by duplicating the primary entity 1:49:21 Entity Framework compresses data efficiently 1:54:20 Understanding performance implications of using Entity Framework vs Dapper 1:56:31 Understanding Entity Framework migrations is crucial for application performance. 2:01:40 Entity Framework 6 doesn't alert about problematic queries 2:04:00 Utilizing toList method in Entity Framework query 2:09:21 Avoid calling C# methods in WHERE clause for better performance 2:11:51 Entity Framework provides faster development speed but may compromise on performance. 2:16:55 Entity Framework is faster to develop but can result in database performance issues 2:19:20 Optimize resource usage for cost efficiency 2:24:28 Entity Framework Core designed for loose coupling 2:26:58 Entity Framework Core is a powerful tool but requires training and experience to avoid pitfalls. 2:31:30 Consider nuanced factors when choosing Entity Framework

[@Ayenam55]

Thanks

[@vkumbaji2010]

Mr.Tim Corey, your courses are superb educational and great resources for learners of all expertise levels.

[@metax73]

If all of your other videos are this detailed, I'm going to watch your entire library. I was expecting to to see a couple instances of how to do something in Entity, but this video was so much more valuable then that.

[@IAmTimCorey]

I try to be thorough in everything I teach. It is all about being real-world ready.

[@RyomaGG]

16:58 You can put in an override for OnConfiguring in the PeopleContext class protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { base.OnConfiguring(optionsBuilder); optionsBuilder.UseSqlServer(Configuration["ConntectionStrings:YourConnection"]); } Therefore your front end no longer knows about entity in this circumstance.

[@milanpospisil8024]

Yes, there are many techniques that can do that.

[@tomthelestaff-iamtimcorey7597]

Thanks for sharing the tip!

[@EricHarmon67]

I watched this video with great interest, and I have some comments to make. I have used Entity Framework fairly extensively since EF 4, up until EF Core 2.x. I didn't get a chance to use EF Core 3.x in production, as I retired three months ago. That should give you an indication of my frame of reference as it relates to EF. Anything I see here is, of course, the way *I* worked, and I'm not claiming my way was the best - only that it well worked for me, and in some cases reduces or eliminates some of the areas that you pointed to as causing you some concern. First, I would never allow any data access tool, EF or otherwise, to create the database for me. Though I wasn't a DBA per se, I created multiple databases for use with my applications, and I always created those databases manually in SSMS. Not only did that allow me to define the tables and columns in exactly the way I wanted (for example, I didn't need to know or care whether EF (or nHibernate, etc.) pluralized table names), but I could also create secondary indexes in the "normal" way in SSMS, without needing to learn anything about how EF data annotations (or fluent API) worked for defining indexes and so on. I just think it's better to have complete control over the database structure. The only thing I ever used data annotations for was for required or max length, which allowed the UI to perform validation of data via Validator.ValidateObject(), et al. You showed the long sp_executesql query generated by EF. I actually never encountered that, as that's something new in EF Core 3.x. In EF "Classic" and EF Core 2.x, one insert statement was sent to the database per row insert (and all the inserts were performed in a transaction). It's interesting to note that the EF team got crucified for that approach, as it caused numerous INSERT statements to be sent to SQL Server when bulk inserting. I myself encountered more than one occasion where I saw an order of magnitude or better performance increase when I used EF addons such as EFCore.BulkExtensions and the like, in the few cases where I needed to insert many rows into the database at once. Now that the EF team wrapped the multiple inserts into a single statement, they're again facing criticism. I'm not any kind of security expert, so perhaps there's a better way they could have reached the same end goal, but definitely sending a single SQL statement per inserted row wasn't being happily accepted. I personally never used migrations, as I found them to be too limiting (at least, when I looked at them; it's possible they gained functionality later on). I found that in many cases when I made a database schema change, I needed to do some serious work on the data. For example, I might factor out three columns from one table and two columns from another table and put them into a new table, referenced by both of the original tables. That kind of work didn't lend itself to migrations, so I wrote a little "framework" for database updates, and then whenever I had occasion to update the database, I filled in the guts of the framework with the handcrafted SQL statements that I needed. So I didn't use EF at all for database migrations. I wrote desktop applications, and I was able to completely encapsulate EF into a .NET Standard 2.0 class library, with no reference whatsoever from the UI project(s). This might be different for me because I didn't write web apps (though I'm assuming this would work equally well for a web app), but I got the (encrypted) server name, database name, user id, and password from a local config file, and then passed those to a static method in the data access library, which cached the information. I wrote a UnitOfWork class that encapsulated the DBContext, and the application made calls to UnitOfWork. The UnitOfWork class instantiated the DBContext, using the cached connection information. The main application never knew it was using Entity Framework at all. Finally, I don't think the query where you loaded all people, addresses, and email addresses was a fair one. You wouldn't load them like in reality that unless you planned to do a bunch of updates to all the data and then resave it. Instead, you'd use DTOs and you'd have a projection query, the same as I imagine you'd do when using a different ORM, or when issuing direct SQL statements. I have, though, on occasion done the same thing in EF Core (2.x) that you said you do in Dapper, which is to issue two or more SQL statements independently, and then merge the resulting data using C#. I understand what you're saying about needing to learn EF before using it, but I would argue that that can be said about literally any technology. I wouldn't want to sit down and try to write an application using Dapper (I've never used Dapper before) without studying it fairly extensively. I wouldn't allow Dapper to automatically create the database, just as I wouldn't allow EF, nHibernate, or anything else to create it. So I think that you're being a little bit hard on EF, as it's an incredible data access technology. In my opinion, the types of "gotchas" that you point out relate to any technology, including direct SQL / ADO.NET. I can easily write a horribly performing, though straightforward, query, in direct SQL. For example, I've seen tons of examples that show "SELECT * FROM Customers", which you wouldn't (hopefully) ever do in real life.

[@IAmTimCorey]

I do like that EF passes a big chunk of inserts to the database to process. That definitely is more efficient than individual inserts. The issue is that in order to do that, you have to enable the use of sp_executesql, which can be dangerous. EF does not use it in a dangerous way but the permissions to run that stored procedure have to be on the calling machine, so that opens up the option for someone to call it directly (a danger). As for not using EF until you learn it, I agree that we should learn everything before we use it. My point was that you should be at a much higher level of knowledge before you use it in a real application. The way it is pushed is to use EF when you don't know SQL or if you want easy data access that "just works". That's what I don't like to see. I've cleaned up way to many of those messes.

[@zacboyles1396]

@@IAmTimCorey thanks for your videos. I like to have tutorials and conferences playing off to the side while I work so I can catch good bits. I've been using EF Core 2 and 3 with Azure web and Azure functions deployments but I've never seen a message to reference the UI or any other project. My data is always in an isolated project and the solution builds correctly. Maybe it's something with .Net standard, I've not spent any real time with it. Also, I definitely agree with what you're saying about developers writing their models without annotations however, those same devs would be the ones to use nvarchar(max) using SSMS lol. You're a bit too harsh on EF there. I might even argue that far more EF tutorials use annotations than typical .net tutorials with SQL. Actually, the c# side of those tutorials typically include the constraint information so to demo validation features whereas the database portion is quickly skimmed over. Anyway thanks for all the hard work, hope I didn't come off as negative with the data types, I just wanted to defend EF a bit. I enjoy how thorough your videos are.

[@bonkers_dave]

Eric, this is three months old, so I don't know if anyone is paying attention. I too am a grizzled veteran with years of experience with EF, but I have to disagree with your level of absolutism on things like "I would never allow the data access tool to make the database for me". In the early-ish stages of prototyping and proof-of-concept, especially in the brave new world of micro-services, the code-first cycle with migrations is a huge productivity tool. For a team, you need to establish a process. It used to be that the "prototyping" phase would last a couple of months and then the system life cycle would be five years. But in the era of micro-services, we're prototyping something or other all the time, and there isn't One-Big-Database-In-The-Middle.

[@user-hz1yc6cw6k]

There is one more point against generating database schema from EF annotations: security. To generate database, EF must be connected with credentials allowing to use DML, wich is too high level of permissions in the most of the cases. And, by the way, in ideal world, database design is the job of database developer and security is the job of DBA. But everything today is being outsourced to replaceable masters of nothing and we have to live in the world where students outsourced as "full-stack" senior develovers do everything at once.

[@henrybotha]

@@bonkers_dave Code first with prototyping is a definite win for me. As soon as this goes live or working on existing data, i don't allow my ORM to make changes to the DB. I code them manually in SSMS and manually update my ORM to access the new structure. From my experience, it is much easier to make a mistake with ORM tooling like EF and you destroy a whole DB/table. Its just simpler to apply those permission levels on the DB level and allow the ORM data access only.

[@vivekkaushik9508]

The fact that is 2.5 hrs tutorial and for FREE on youtube is ming boggling. Most people share knowledge in general. Thankyou so much Tim.

[@IAmTimCorey]

You are welcome.

[@gasparottogui]

Hey Tim, thanks for another great video! I've been learning a lot in your tutorials and it's impressive to see how deeply you understand the language and how clearly you explain it. Thanks for sharing!

[@IAmTimCorey]

You are most welcome. Thanks for the encouragement.

[@viajeromero]

You are the best programming teacher I've ever met. Thank you so much for this content.

[@IAmTimCorey]

Thank you!

[@TehDarkWolf]

I feel like it's still important to learn it for people who are planning to get into professional industry. EF is widely used in many companies ranging from small to large, I honestly I have heard of dapper until I came across your channel. The best way to learn is to use the frameworks, if you consistently avoid well-known frameworks you won't really grow as a developer and limit yourself in the professional world.

[@IAmTimCorey]

True. You will face it so you should learn to do it right. I would recommend learning it later on in your C# development training. In my Foundation in C# course series, I teach it in module 8 (out of 10): www.iamtimcorey.com/p/complete-foundation-in-c-course-series

[@objectaware5296]

I agree. Most MS Stack shops use EF but you should have a good knowledge of SQL and Database design, in most orgs, you're the DBA. If the shop does not have formal code review, find the most knowledgable people in each discipline and ask them to review your code. You'll learn something most times.

[@joeyf9826]

Try as we might, I don’t know if we’ll ever abstract away from the details of how DBs work. EF is somewhere in the middle of the abstraction, where it tries to hide the DB details but will also burn you if you don’t know what SQL is being executed. All too easy to write a query that ends up pulling a million rows into memory.

[@InsolentDrummer]

The reason I find Tim's channel so useful is because he always explains why we do certain things one way and not the other and not just because he said so!

[@IAmTimCorey]

Thanks!

[@mehedihasanopu5666]

Thank you Tim Corey. It's a great chance for us to learn from your courses. For checking if there is any record in table, Any() functions should be used for better performance. Count() has to read the whole collection of the table but Any() immediately returns after reading a single record.

[@IAmTimCorey]

Thanks for sharing.

[@nickoaks5143]

I understand what you mean at @15:30 about feeling weird with the Web project knowing about EntityFramework. The way I solve this is by creating a extension method in the DataAccess project (we'll call it .AddDataAccess(this IServiceCollection services) ), and then inside of this method I wire-up the .AddDbContext(). Finally, in the web project, you can simply call services.AddDataAccess() inside of the ConfigureServices, and the web project doesn't need to know anything about EntityFramework. Works great. Thanks for all of your videos!

[@tomthelestaff-iamtimcorey7597]

Thanks for the insights.

[@Namynnuz]

1:14:30 instead of .Count() == 0 it's better use .Any().

[@IAmTimCorey]

Why? The SQL command it runs is the most efficient command it can run. Is there a different benefit?

[@Namynnuz]

@@IAmTimCorey that's a better practice with LINQ overall, because implicitly it should result the same thing. But, there's difference in LINQ implementation and .Count() is kinda slow operation. I'm aware that EF mapping LINQ to actual SQL querries, but it also should convert .Any() to correct SQL form (similar to yours, which is .Count() == 0). But in every other places, it's just a better practice overall. So, to maintain consistency.

[@IAmTimCorey]

Ah, gotcha. Thanks for sharing!

[@JasonDias7]

When you use Any(). executed sql looks like this SELECT CASE WHEN EXISTS ( SELECT 1 FROM [Person] AS [e]) THEN CAST(1 AS bit) ELSE CAST(0 AS bit) END

[@silverbane0069]

I wrote an extension method that would return true/false based on a Take(1) based on the where clause, this was a few years ago, but in my testing on a decent amount of data, it performed way better on the large datasets I was working on, since it was stopping as soon as it got the first record as opposed to looking at the entire dataset.

[@salmanahmedazmi3084]

Really well made and I love how you show the simple things that are so often missed.

[@IAmTimCorey]

Thanks!

[@greenwalmart]

Tim, you did an great job covering this topic. I try to tell people that programming is the last thing that you do. And your videos demonstrate this. You have to know exactly what you're doing or pay the price on the backend. Awesome video!

[@IAmTimCorey]

Thank you!

[@justtohide]

While I didn't know about this channel, when I was trying to write migrations from other channels, no one went that deep, they didn't show the errors, and so I had a problem every time I found a problem myself. in the end, I lost my enthusiasm and instead of writing with migration, I switched to writing db first. when I discovered this channel, everything was great. Thanks

[@IAmTimCorey]

I am glad it was helpful.

[@WhatIsBinary]

Tim Corey DOMINATES this market. The best quality videos. The most understandable videos. An absolute asset to YTs education sector.

[@IAmTimCorey]

I appreciate the kind words.

[@GuySymonds1]

Where was this tutorial when I was trying to learn EF so many years ago. Really well made and I love how you show the simple things that are so often missed like where the PackageManager Console is in Visual Studio. I'll be watching a lot more of these videos, keep up the great work.

[@IAmTimCorey]

Awesome!

[@tmfink10]

Hi, Tim. I'm wondering if you've been keeping tabs on the development of EF Core. If so, do you feel they have made any significant improvements since you produced this video that would address any of your core concerns? Or, do you feel that any progress has been made in other areas that could help to offset any of your concerns?

[@j_ason_rpg]

Probably not considering I just created a new VS2019 project with EF Core and all of the configurations are still present as they were when this video was uploaded, including all the nvarchar(max) nonsense

[@markippo]

@@j_ason_rpg tbh how do you expect them to be any different? How autogenrated code should know your sql string precision if it's not set? Nvarchar(max) is of course very inefficient approach, but quite wise as long as information is not given. If characters are less than 4k, it performes as varchar, if length is exceeded, it is converted to text. Entity Framework or any ORM systems aren't the problem, people are and their thinking that orm realeses them from knowing sql. No... If you wanna go abstract, you've got to know the foundation of the abstraction, otherwise you'll end up like all of them - whining about inefficienies, deadlocks etc. Want to work with relational databases, you've got to learn sql. Period.

[@j_ason_rpg]

@@markippo Yes, I wrote that comment at a time when I knew a lot less about the subject than I do now. Most of that comment was me probably trying to figure out what tools I wanted to learn

[@davestorm6718]

@@markippo - I've found that EF is too "black box" for my tastes. But then again, I come from a database first (and have for 20 years) approach to applications, and it's never been an issue for me. Also, when I see code-first implementations, it appears that you end up having to muck about the database anyway (not to mention security issues, the ridiculous number of superfluous calls made to the database by EF, etc). This and, honestly, how often do you change your database to a completely new system? In 2 decades, I've only seen it done once, but then again, the ENTIRE stack was changed from DotNet/SQLServer to LAMP (and it was, to say the least, the dumbest move I've ever seen a company do, all because some idiot didn't want to pay a few grand for SQL Server - they blew a million bucks in labor to save a few grand).

[@frankolee4892]

I found Tim's video incredibly useful and it did a fantastic job at highlighting issues. I don't know if this is a new feature or perhaps I missed... but I found that EF would not run a migration which would cause a truncation of a string (and hence data loss) via Update-Database in Package manage console, and would throw error when attempting to apply migration at runtime (docs.microsoft.com/en-us/ef/core/managing-schemas/migrations/applying?tabs=dotnet-core-cli) This was discovered while playing around, I haven't read the docs so can't confirm how safe this safety net is! Check for yourselves before risking it on production data!

[@idis5702]

you can use Iqueryable method for where clause, like predicatebuilder that is functional and also it is easy to use

[@IAmTimCorey]

Can you show me an example of what you mean? I'm not quite understanding what you are saying.

[@Doomchild_]

@@IAmTimCorey I would change the return type of the ApprovedAge method from bool to Expression and return x => x.Age >= 18 && x.Age

[@torrvic1156]

Your lessons are pure gold Mr. Corey! Some things you said I learned the hard way via trial and error myself but other things you advised can’t be underestimated. Such a good advices you are giving to us! You even know about War and Peace book and it tells us as to how knowledgeable and intelligent you are. I am amazed by your charming personality Tim! Thank you so much!

[@soucianceeqdamrashti8175]

What I love about this video is that you explain each topic with the right level of detail and in a succint and informative manner. Even someone who has primarly used Dapper loved the content and learned a lot.

[@IAmTimCorey]

Excellent!

[@gedwistle1974]

Not sure if this has been addressed in comments already, but for your first issue about having to reference EntityFrameworkCore from the web app in order to call services.AddDbContext, you can simply reverse the dependency. I use a static method on my Context partial class that takes the IServiceCollection as a parameter. This allowed me to remove the reference to EntityFramework from my web app project all together.

[@IAmTimCorey]

Thanks for sharing.

[@lolop2576]

I consider myself a pretty experienced EF developer, but had only just learnt about the drawback of using Includes from this video. I had assumed it did something along the lines of QueryMultiple in Dapper. Just shows it's always worth looking at videos on topics you consider yourself well versed in. One thing I was waiting for you to bring up was projections. Using Select statements is an extremely important part of making sure that EF runs smoothly for me. It solves the issue of Include, and removes the change tracking which is another big cause of slowdowns. Using projections you can get near identical performance to Dapper, while also keeping all the benefits of EF core. One of the most important things for me is the compile time safety of my queries. Admittedly I haven't watched your videos on how you use Dapper yet so I'm not sure if you've addressed this. I also think using the right tool for the job is an important aspect. If a query is complex and needs to be hand crafted for performance, writing the SQL manually and using dapper is the better option. If you just want to pull a few fields from a table or two and put it into a VM/DTO, I think EF with projections is usually better. I'm not against using both in the same project and using EF for 90% of my needs, and Dapper for the last 10% of more tricky/important aspects of the application. Lastly, in case you didn't know, you should be able to change the 'Logging.LogLevel.Microsoft' in the appsetting.json to be 'Information' and all the queries run by EF core will be logged to the ASP.net console. I find it much easier to look at the queries as they go through there than trying to filter through the junk in SQL Management Studio. Just my 2 cents, great informational video overall, especially for newer developers!

[@IAmTimCorey]

Yeah, I just touched on some of the topics. There is a lot to cover. I'm glad you enjoyed the video.

[@dzllz]

Great points. Select solves the issues of include

[@Clrscr112]

To be honest EF most of the time is fast enough. Emphasis on the enough and not the fast. We have a fairly large system backed up by EF6 and users never mentionted anything about poor performance but to be fair we made precautions and optimised the performance heavier parts. For us the faster development outweights the performance penalty which is not a real issue (at least for us).

[@IAmTimCorey]

Yep, it all depends on circumstances. The danger will be if you get acquired and take on a large number of new clients. That can be an issue (I've seen this happen to clients). The good thing is, like you said, you've optimized the heavy parts. That goes a long way.

[@andrewelmendorf2602]

Same here. I have 3 fairly large databases accessed with apps using ef core and would have a hard time justifying a switch for any new projects(just started another with ef core).

[@Cromfeld]

Dear Tim! I've got a new job, thanks to Your videos! Keep up the good work!

[@empathetic24671]

Hey Tim, your content not only helped me to understand code and program, but also helped me to see the problems in a completely simple way. Your way of teaching and talking out the solution is unique & simple. Thanks for that.😀

[@IAmTimCorey]

You are welcome.

[@AndrehHimself]

Just passing by to say: THANK YOU TIM! Your videos are awesome and are really helping to move towards a dev career, what you do for the community has granted you a place in heaven. Keep up with such amazing work, cheers!

[@IAmTimCorey]

Glad you like them!

[@rakip3188]

Small correction: Ascii has 256 characters Unicode has 143,859 characters Thank you Tim for your hardwork in putting these videos together. Greatly appreciated 🙏

[@akuskus]

And even smaller correction: ASCII is written in all capital letters.

[@ahmedifhaam7266]

@@akuskus that's not really a correction of data, just convention, OP actually gave a correction by providing new facts.

[@akuskus]

@@ahmedifhaam7266 true

[@anubhavdebnath2747]

small correction ASCII should be written in all capital

[@E-Dh]

i am currently using this video as a go to guide whenever a friend of mine mentions using EFCore. Thank you Tim, you really are awesome !

[@IAmTimCorey]

You are welcome.

[@timrobertson8242]

Another Awesome real world explanation. Even the preamble with the ground rules on commenting and disclaimer that everyone can have a valid opinion - priceless! Fortunately, it looks like I’m coming to the party at just the right time for .NET and learning C#. I’m working on a transition with a friend from a PowerBuilder based product to work through what makes sense to move to C# and .NET Core (for the computational / Data crunching part of the solution). You’re content has rapidly gotten me oriented and confident about iterating through a solution. Thank you again! -even more: You’re example right at the start is a Person with multiple addresses and emails - Real World requirement - and an explanation that communicates and causes the viewer to “think” but still simple enough to keep engagement. Wow!

[@tomthelestaff-iamtimcorey7597]

Thanks for growing your skills with Tim thru this video.

[@torrvic1156]

Tim also knows about War and Peace book! It is astonishing by itself. He is not just a great programmer and teacher but he is a man of culture also.

[@JabmarMusic]

Your's course not only explains how to build a program in Visual Studio but also is a great lesson of how to speak in english. Big thanks.

[@IAmTimCorey]

You are very welcome!

[@qutiephoebe2154]

You dont find these best practices and tips from other videos... They just teach you how to write code... That explanation and difference on approved age in the where clause is bravo!👏👏👍👍

[@IAmTimCorey]

Thank you. That's what I attempt to do with all of my videos.

[@alanskaev]

This video is so detailed and thorough it shouldn't even be free

[@IAmTimCorey]

Thanks!

[@UnknownMoses]

No it should not be free.

[@bengardiner5880]

@@UnknownMoses i mean im quite happy is free

[@imanidioli]

Totally agree with you

[@HekmatKhyber]

Hummmm, in my whole development life this is the first time to see this type amazing explanation. Great job.

[@IAmTimCorey]

Thank you!

[@HekmatKhyber]

@@IAmTimCorey now you are our instructor, I have learned much techniques from your best tutorials.

[@andrewbezzina87]

Now that .NET 8 is out and we are on EF 8 are there some points mentioned here that no longer apply? Has MS improved on some of the negative aspects?

[@RiGoRmOrTiSUK]

absolutely amazing video. the way you teach things is so easy and comfortable. perfect pace and complexity. quick question. is much different in .NET 7 to what you explain here?

[@IAmTimCorey]

EF is more efficient and has some new features, but my recommendations don't change.

[@RiGoRmOrTiSUK]

@@IAmTimCorey if you are making changes to an object and cancel those changes how would you recommend rolling back the changes, just pull the object from the DB again? It's something that's enticed me to move to EF since it can track changes. In the past I've resorted to serialising an object but thats depreciated and not recommended due to security concerns I believe. A regular deep copy doesn't take into account changes on any attached objects, just properties I really want EF to be an option because pulling the object back from the DB on cancel seems so inefficient. Your video convinced me not to use EF so looking for alternatives

[@sufyaniqbal8939]

This One lecture is better then my half semester in uni. Thank you so much for your kind effort ❤️ Love from #Pakistan

[@IAmTimCorey]

You are most welcome. Thanks for watching.

[@sufyaniqbal8939]

@@IAmTimCorey I really appreciate your work. Keep it more and more. I will try to invite my friends too. come and learn your advance level concepts.

[@leeanderson9486]

This is exactly how I felt about EF. It’s analogous to a piano, press all the white keys, ooh this is easy but… The slickness of the tooling doesn’t give the developer enough of a heads up toward the power it wields under the hood and only an advanced developer would be able to infer/reverse engineer it from an inherent understanding of SQL server / db design.

[@get_ready]

Amazing video. I'm pretty new to EFC and total newbie with SQL. I learned a lot from this video, and it made me realize that I should in fact invest more time to learn what I'm working with. Thank you!

[@IAmTimCorey]

Excellent!

[@saturninramirez1107]

I'm French , and i've understnd every things you explain , THANK YOU VERY MUCH , I will start to lurn DAPPER , with yours courses

[@IAmTimCorey]

I am glad it was so clear and helpful.

[@freerv-erveervvr]

Hi Tim Corey, Thanks For This video, I am from Uzbekistan and i am your student! You are best teacher.

[@tomthelestaff-iamtimcorey7597]

Thanks for sharing. I kinda want to get a world map and plot where all out students live. It would be impressive, I am sure.

[@TheMaKasss]

I knew everything you said. But still good to know, that there are such a good tutorial for people who interested in what they are doing. Good job.

[@IAmTimCorey]

Thanks!

[@nikoskondylis5618]

Thank you for all your excellent tutorials! One side note I would like to make if I may. The EF design tools can be installed in the EFDataAccessLayer class project. After you install the tools in the class project, make this project as startup project from Visual Studio solution, run your migrations from PM> and switch startup project to UI project when you want to run the application.

[@IAmTimCorey]

Yeah, it is just a pain to do so.

[@MohammadKhanfer]

Hi Tim, we are selling a white labeling product for many clients, each one of them has a totally different application & database version. One of the major benefits that we have in EF, as you said the tooling is great in EF, so we are using it to manage Migrations and to generate it, also we integrated that with our CI/CD so all DBs automatically using the same tooling. What is the better alternative here? What about doing CQRS and using EF for write operations at least to make things faster in development. And thank you for the great video.

[@IAmTimCorey]

It really depends on your situation. Again, if you are an expert at EF and are careful with it, it can be an amazing tool. You can use SQL Server Data Tools to manage migrations and CI/CD right in Visual Studio ( kzbin.info/www/bejne/n5unlHt9rd6ke5Y ) and then use Dapper for data access. It just depends on the situation, the team, etc.

[@ashraflambe]

Hi Tim, thank you for great job towards C#. I was thinking that this language is losing market ground. But now with your detailed videos I changed my mind and came back. Thank you again.

[@tomthelestaff-iamtimcorey7597]

Welcome back and thanks for trusting Tim for growing your skills.

[@nussberger]

The first long video on youtube I watched from beginning to end. Worth every minute. Thank you for your hard work, smooth voice, and deep knowledge!

[@IAmTimCorey]

Glad it was helpful!

[@acoupe1970]

I find that data annotations are essential for getting more control on creating a model and they are easy to understand

[@IAmTimCorey]

That's good.

[@aminebenhebba1891]

I personally hate them (in general I hate anything that pollute any abstract or higher concept like Entities just for some details) prefer using Fluent API with overriding onModelCreation method and pointing to mapping classes for my entites implimenting IEntityTypeConfiguration interface. I find it cleaner and better practice. As uncle bob said : jumping from higher concept to lower ones in the same line of code is just a rude code to write. A bit like this on the PeopleContext class : protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.ApplyConfiguration(new PersonEntityConfig()); modelBuilder.ApplyConfiguration(new AddressEntityConfig()); modelBuilder.ApplyConfiguration(new EmailEntityConfig()); base.OnModelCreating(modelBuilder); }

[@aliaksandrbortnik1874]

FluentAPI gives more control than DataAnnotations. However, for stuff like simple constraints and limits, for instance, required, length and some more I prefer to use annotations to keep them right together with Entity class. It becomes reasonable in cases where there are 10+ entities in your DB.

[@acoupe1970]

Aliaksandr Bortnik I quite agree with you there, Fluent is very useful in that situation

[@chadwad12]

I'm watching this video as a long time user of Entity Framework (before EFCore was a thing) and as someone who successfully uses Entity Framework Core on enterprise applications that has a lot of data. I wanted to bring up a quick note though of you talking about that you "hate" how EF could technically expose your DB Credentials if you developed it on a desktop application. While that is true, I could make that argument for any desktop application that connects directly to a database. You even mentioned it in the video, that the user technically owns that one part. Any desktop application that connects directly to a database will have to somehow put username and password on the users system. Be it encrypted (and you said it, user technically owns one part of that key) and compiled into the code, it's still possible for me to mess around find it. While there are pros and cons I myself would most of the time develop a desktop application to talk to a mediator, like some kind of web API. I can manage access easier that way and can manage what is actually going in and out of my database. I could even develop some type of cache before it gets to the database, but that is whole different topic. So for most systems I end up building some mediator to talk to a desktop application, unless I am building like an offline only application. Then at that point if the user wants to "hack around" on the local db it talks to then go right ahead. So for me I guess I just don't think it's fair to just really talk about EF there. I feel any desktop application that connects directly to some remote database can have that issue, no matter what you are really using at the data access layer.

[@erikverboom5383]

My thoughts exactly! I loved the video, very educational. But as far as I'm concerned the tone could've just as easily been something like: "You want to use EF? That's cool, but this is what you need to be aware of!"

[@IAmTimCorey]

I agree with you but I think you missed one key piece of my argument about the credentials. It wasn't just that the credentials are exposed (as they are with any desktop application, as you pointed out). It is the level of permissions those credentials need to have. They need to have essentially full administrative access. They need to be able to directly access tables for read and write, they need to be able to create and drop objects, and more. If you use an ORM like Dapper, you more easily have the option of only allowing stored procedure access to your database (I know you could technically do this with EF but at that point it is a lot of overhead for essentially just...Dapper). So even though the credentials are exposed, they only expose what the application already allows them to do and not really anything extra. Sure, if you didn't allow regular users access to a stored procedure they might be able to call it directly using the credentials but that is a whole lot less than being able to run "drop table" or "delete from" commands. I definitely agree about the middle layer (or mediator, as you called it) like an API. I actually use that technique in my TimCo Retail Manager series. That does eliminate that particular issue (well, 98% at least).

[@mhdb96]

Man! your videos always have fully explained satisfying answers to my questions. Keep up the good work

[@IAmTimCorey]

Thank you!

[@jhtaljaard]

A video of this quality is rare - thank you so much for this. I also learnt a lot from it. Well constructed and very clear. Thanks for covering some of the pitfalls and nuances. :)

[@tomthelestaff-iamtimcorey7597]

Thanks for watching and promoting Tim's videos.

[@Thespartanassassin1]

I've been looking a lot of ef guides. I also have prior experience with it but never created a project from scratch myself, this guide is absolutely the best one I've found so far. Superb job and the flow you have is absolutelt great! Thanks a lot you saved me a lot of research time

[@IAmTimCorey]

Awesome! Glad I could help!

[@ioannisstefanou9140]

Hey Tim, great tutorial. I enjoyed the details on where entity framework falls short -- they actually gave a great insight to how this system operates behind the scenes. I would like to propose a suggestion for a tutorial as to how would you implement a repository/unit of work patter on top of entity framework. Thank you for all your hard work. Subscribed

[@IAmTimCorey]

I will add it to the list. Thanks for the suggestion.

[@ignaciolaborde9166]

No, EFC already implements a repository/unit of work pattern, so adding another layer on top is not helpful. You can use the dbcontext directly

[@shanegray8]

Love this. Been making similar arguments for project development for a few years. This is just explained so clearly where now I can just send a link! Good man yourself

[@IAmTimCorey]

Excellent!

[@objectaware5296]

This really doesn't explain anything other than you need to have knowledge and experience with the tools you're using. If you write poorly stored procedures (sp) or if EF does they are still poor. For example, if you don't understand that left joins pull duplicate data and write the sp then you're no better off you lack experience and knowledge. If you understand EF lazy loading then you don't need to pull the data from the address and email tables it will be done for you once the data is needed with EF.

[@larsmagnusnyland9588]

@@objectaware5296 Sometimes lazy loading can be worse than duplicating data, it really depends on which context you use it. If you use it to load thousands of people, then getting all their addresses separately that's good. However, use it in a for-loop to check some requirement for that person, or do some sort of lookup. Not good. This is because a new query is made to the SQL server for each property that is lazily loaded. And using the network card to send a request to a server, and wait for the server to do some processing, then returning a result is way slower than just reading memory. Even if the request takes 5 milliseconds, a thousand iterations on that will be 5 seconds. I'm sorry I have some trauma from when I started working a project that did this, and still does this some places.

[@objectaware5296]

@@larsmagnusnyland9588 Ah so you've gained experience with lazy loading which is my point. Whether I use EF or Dapper if I don't have the experience with the library and SQL Server mistakes can be made. Experience or lack of it is what makes code reviews so valuable. BTW, If I understand the scenario you're describing and know what I'll need in the dataset, I may just use a Function table procedure, done at the SQL server, returning an Entity Dto object.

[@codefoxtrot]

As of EF Core 5.0, Split Queries have been introduced to solve the cartesian explosion problem that was described in this video. This feature significantly improves single query performance, and I was happy to see it! Granted this does not solve the fundamental problem that by default, it's easy for a newbie dev to get into trouble, which is your point. Especially when I tell you Split Queries, which can be enabled globally, is by default turned off! But nevertheless, for those of us that are experienced and read documentation, EF is now extremely viable.

[@IAmTimCorey]

Yep, that's a great feature. You are right that it doesn't solve the new developer issue but having that option is really important.

[@Hamza-Shreef]

Well i used to do explicit loading to solve it , don't really know if they have such feature thank you bro

[@NoOne-oy5vs]

Wow, this is really informative. You are correct that EF is really easy to use with many amazing query tools, code-first migration and etc. It is one of my favorite backend framework when I do project. However, I have got interned in one company that uses EF, we faced some issue with EF and some of them is what you mentioned in the video. It was years ago, we were using .net core 2.1 at that time. I am not working with them anymore, but I heard that they ended up rewrite partial of the project to optimize it. This video taught me a lot, thank you very much!!

[@IAmTimCorey]

You are welcome.

[@zoltan.halasz]

Simple, clear, easy to follow lesson on this important topic.

[@IAmTimCorey]

Thank you!

[@fiqriismail]

Thank you for this great tutorial. Cleared a lots of doubts I had.

[@IAmTimCorey]

Excellent!

[@lenardbartha6722]

I like EF Core, much more than EF 6. Version 3.1 is a great improvement, just waiting for the documentation guys to catch up since the docs are still on 3.0. I think because MS is so invested in it, it has a large community and support, which is a big plus.

[@IAmTimCorey]

It has come a long way.

[@roodborstkalf9664]

They have only five or six people working on the Entity Framework team. That is not very invested in my opinion.

[@lenardbartha6722]

@@roodborstkalf9664 On github, the shows 181 contributors. Now I know not all are Microsoft employees, how do you how many are on the team? Where did you get the 5-6 people?

[@roodborstkalf9664]

@@lenardbartha6722 : They said this themselves somewhere on their github pages where they were discussing what things to prioritize.

[@lenardbartha6722]

@@roodborstkalf9664 Hmm, that is good to know.

Thanks for the video. You smashed it. You showed key points in terms of performance, diagnostic, debugging and others. However, I disagree in these points: 1 - if an inexperienced developer write a Data Access layer using dapper the consequences could be (IMO) 10x worse than using EF as an inexperienced developer. First, most of the time they (inexperienced devs) will handle the connection by themselves ( handling transactions, open-close dB , etc) they will create the UoW and Repo, they will do simple queries that maybe (I’m almost sure) will be not more performing than the EF ones, the data access layer will be not as tested and documented as EF, they will spent more time due to creation of all the data access layer, and more. Thus, if we compare what you can achieve as an inexperienced developer using both of the tools, I would argue that using EF can be less harmful and more efficient, than an inexperienced developer trying to create their own custom ORM or Data access Layer. 2 - In most companies there are developer team and database team. In my view devs would relegate the migration/maintenance/performance of the DB to the dB team and would work together when changes impact both sides. 3 - Premature optimisation is the root of all evil 👿. I would focus at the beginning in achieving then when performance issue are identified (hopefully, performance, loading, peek testing are done) then I would optimise the bit that cause a bottleneck (this should be done by someone with experience though) 4 - The learning curve is shorter using EF. Most .net developers will learn C# and then will learn some SQL. You could start delivering or producing work with only knowing C# and lambda expressions. However, I believe that we need more videos as the one you did, as they show a view on both worlds (C# - SQL Server) and of course learn sql as much as possible. 5 - I would consider to explain how you could change from SQL Server to another database vendor, using Dapper/EF and also would talk about how to change completely or handle different DB vendor. Cases: 1 Imagine I change the code to use only MySQL. 2 - Imagine I deploy you client with different database, ex Oracle, MySQL, Postgre DB. What would happen, what need to be done, how Dapper vs EF core or EF 6 would handle that, is that even possible or is the kind of things that you need to tell to your clients to f... up? Other than that, I love the video and I learnt lots of it. Thanks 🙏🏼

[@IAmTimCorey]

1. I definitely think that you need to understand what you are doing before you write a data access layer (regardless of Dapper or EF). I do think that it is easier to make something without knowing anything if you are using EF. That's my issue. 2. I agree that this is ideal. If you do have two teams, why are you using code first EF? Dapper seems the more segmented and easier to keep performant route. 3. I would say that this phrase is the cause of a lot of the evils. There is a difference between premature optimization and writing good code. If you architect your application in a way that is inefficient, it will take a lot of rearchitecting to optimize it later. This introduces more bugs and causes more issues. 4. I would disagree that the learning curve of EF is shorter. It appears shorter but that is deceptive, as I demonstrated in this video. You think you understand what is going on until you hit production and it blows up. I had a lot of people tell me I should have just lazy-loaded my data and then everything would be good. That only works if you aren't doing a large display of your data (datagrid, etc.) If you do, then you actually made the problem worse. If you use EF, you NEED to understand SQL well to do it right. In a lot of cases, you might actually need to learn SQL better than if you were just using Dapper. If you just learn the C# side of things, you won't understand what is optimized and what is not. 5. My C# Application from Start to Finish course does replace the SQL connection (Dapper) with a custom text file system for data access. I also use pretty much the same Dapper code for SQL, MySQL, SQLite, and more in my various videos. I like the idea of showing how to swap out though.

IAmTimCorey thanks for answering. I really appreciate that you took time to read and reply my comment.

[@iandalrymple7255]

"If someone's opinion about how to write C# makes you angry then you need to re-evaluate your priorities." This intro made me chuckle. So true.

[@IAmTimCorey]

lol, glad you enjoyed it.

[@Guacamole42]

Awesome video! Thank you for making this one. I like EF very much. It hides the database mechanics once you have set it up correctly but when you get a problem later on, good luck with that. Great teachings coming from you about EF, I love it!

[@IAmTimCorey]

Thank you!

[@keithnicholas]

when you say "hide database mechanics" you need to be careful, it implies you're encapsulating this lower level thing. But that's not what is happening, what is happening is you are hiding stuff you don't want to have to think about. Which is fine, it can simplify things. But what you are hiding is actually a much much richer higher level system for dealing with relational data. You are dumbing things down and bridging it into the C# world where you can deal with data in a more restricted way.

[@willitoz06]

15:50 You could wrap you EF into a service (IExampleService) in your Net Library project, then reference that service in your front end. That way, you frontend won't know you are using EF on your Net Library.

[@IAmTimCorey]

Yep, that is a possibility.

[@simonlester4316]

Thanks for making this video, was blindly using EFF Core until I watched this full video, man, what an eye-opener

[@IAmTimCorey]

Glad it was helpful!

[@celebrim1]

So my experience with EF is that its strengths are exactly what you would expect it's strengths to be if you understand how it works and you rolled your own. What EF does well, and what might tempt me to bring it in as a solution to a specific problem, is build a search engine. Because Entity Framework at it's core is a dynamic SQL builder. If you don't know really what combination of filters are going to be applied to the data set then entity framework provides a really intuitive and straight forward way to build dynamic SQL, which is something you need if you are going to build a performant data search when you don't know exactly what where clause you are going to need. And that's great, but the tradeoff is bad. For all other problems, I find that Entity Framework is a toy solution. And by that I mean that it makes tasks which are simple and straight forward, like atomic CRUD operations easy. But, the characteristic of a toy solution is that it makes non-trivial tasks harder and more complex, both to create and to debug. Once you start getting to sufficiently complex real world operations, which are non-atomic, which ideally will involve reading multiple datasets, and so forth, then entity framework doesn't make things easier than rolling you own straight forward DALC's with old fashioned ideas like connections and readers. It in fact makes it harder. There are more unintended side effects and more work involved in avoiding unintended side effects. If you start working with 40 joins, some of which are filtered, then the fact that left join is not naturally supported by the syntax and the fact that your LINQ itself starts getting really complicated, and fact that you are forced to hacky patterns like unnamed objects or projections, which result in massive potentially hundreds of lines long single statements that are inherently brittle and defeat any advantage of EF in the first place. I find you still have to end up creating cache objects because EF's caching isn't intelligent enough to manage itself and managing yourself is harder than just rolling your own. And don't get me started on the fact that it can't do multiple datasets but instead goes cartesian nuts by trying to push everything into a single result set.

[@IAmTimCorey]

Yep, pretty much.

[@kawthooleidevelopers]

Thank you Tim for this video. I have been battling with myself over EF6 and Dapper. I'll bite the bullet and go with Dapper. :)

[@IAmTimCorey]

You are welcome.

[@ankuronlyu]

Thanks Tim for this nice video, we are already using EF Core in production and in the beginning we got some performance issue but now we have optimized the LINQ query.

[@IAmTimCorey]

Keep those skills up. More issues will come up, so knowing how to debug performance and improve it will be critical.

[@novemberdev8292]

I use EF to build the Tables and do Insert, Update and Delete, but then I use Dapper for advanced SQL queries, it has been a blast so far!

[@IAmTimCorey]

Great!

[@elenafartukova1656]

Hi Tim, thank you for the great video! Every minute is worth watching!

[@IAmTimCorey]

You are welcome.

[@mohammedkhalil7051]

Hi Tim, for nvarchar(max) and any type that can cause performance issues, I think we can use DB or model first approach not code first approach, so we can have full control about columns type, and EF will generate models with correct types we want, or we can use annotations as well to control each field attributes in code first approach.

[@IAmTimCorey]

Sure, we could do those things and if you do, EF will perform much better. The problem is that people don't do either of those options typically. That's what I was pointing out.

[@sergeiarhipenko872]

Thanks a lot for your clear pronunciation it's really easy to understand especially if you're not a native speaker!

[@IAmTimCorey]

Glad to hear that!

[@alexaka1]

1:48:56 I think this is solved by EF Core 5.0 AsSplitQuery() modifier. It splits the joins to separate queries, and then does the join afterwards, probably in memory.

[@IAmTimCorey]

Great! They are always working to make EFCore better.

[@zulhishamtan4308]

I always believe there is any no single technologies is being designed 100% perfect. There is always a PROS and CONS. This is video is really good. I love to use EF for small project which requires simple database schema since EF makes life easier of course which those best practice apply. Its makes our code cleaner and easy to read and maintain. Migration helps keep track the database design. Code first simplified a lot of works. Linq can minimized a lot of C# line of code. On top of that, EF helps a lot when talking about design pattern especially unit of work....I believe.....Well, correct if I were wrong. Thanks!

[@IAmTimCorey]

Just be sure to do the work needed to design the database well.

[@BryanPollardPhotos]

Thanks Tim! I wish I had this a couple years ago to share with my junior developers. I have had the same reservations as you for many years about ORMs in general. I have seen them totally derail an application once it hit production. My team used EF for the first time a couple years ago and I have been fairly happy with it, but this video pretty much sums up my feelings about it. As a hiring manager, it has been a challenge to find newer developers that can work "without the net" of an ORM. I believe that knowing how to do both is critical to being an experienced developer.

[@IAmTimCorey]

Thank for sharing from that perspective. Appreciate!

[@absentbrainded]

This was really helpful for me TIm. I really appreciate the careful and balanced presentation on the topic. I'm an experienced SQL developer, but brand new to EF and C#. Many of the topics in this video were eye opening for me. I'm not sure if I'll have the ability to use Dapper on this client project, but you helped me at least be well aware of some of the biggest pitfalls to avoid.

[@IAmTimCorey]

I am glad it was so helpful.

[@SpaceShot]

This is such a great roundup, taken from the point of view of using EF and diving into the beginning and continued maintenance and improvement of the application, and then going over how it doesn't fulfill its promises. I try very hard to avoid being that grumpy old dev who says "just learn SQL" but as you've pointed out, you need to end up knowing it anyways. And SQL is such a fine domain specific language for relational databases that it seems like all you're doing is learning this abstraction in between the concrete need to know and use SQL anyways.

[@IAmTimCorey]

Thanks Chris. Haven’t talked to you in what seems like forever. Hope you are doing well.

[@SpaceShot]

@@IAmTimCorey Hanging in there... can't wait to see you again at an event. I'm a fan of your work. I keep up with C# thanks to you and I really appreciated this thoughtful dive into EF with an objective yet skeptical point of view. Every time I think there is something more to teach I realize it's covered at IAmTimCorey... no joke...

[@mereblood]

I am SO excited to see you finally covering this topic!

[@IAmTimCorey]

Great!

[@graciie77]

I have a question about the way you put your models and context in one class library as opposed to using two class libraries like this: AppName.Models(class library with the models) and AppName.Data(class library with the dbcontext) which one is better and does it matter?

[@soarwing52]

went through the whole video and do along with it. I'm deciding whether use Dapper or EF Core in this moment, the deep analysis made a long video never felt long, all information is really valuable. thank you!

[@IAmTimCorey]

Glad it was helpful!

[@mikim.6338]

2:08:08 - but message in the exception tells you that you have to change your query in a way that can be translated into sql query OR put .ToList() before Where(). It gives you choice. So don't blame message for that.

[@IAmTimCorey]

I'm not blaming the message. The message is new, and I applaud the message. However, bringing down all of those records is not a wise idea. That is what I'm cautioning against.

[@ppcuser100]

Hi Tim, I have a question regarding your explanation at minute 1:49:55 that you explain about sending the data "redundant compared to Dapper" over the wire. I thought that the optimization of the information should be done on the SQL server, as so did you mentioned it few seconds later (or I misunderstood) because you said that only 100 compressed Person objects arrive. Could you please explain: 1. Where the merging of the duplicate records is done? on Entity Framework inside the application or on SQL server? We saw eventually only 100 "Person" objects, So where is the "merging" (1200) process is done? 2. If in the example you provided application downloaded 1200 recordes instead of 800 (Dapper) ?Why you mentioned "only 100 compressed Person objects" ? Thank you 🙏

[@IAmTimCorey]

With Entity Framework, it downloads all 1200 records and then consolidates them into the 100 actual records. So that work is all done in C#, but it is hidden from view. As for Dapper, you get to download just the required records. That may mean doing multiple queries. I don't remember the specifics of the query I did, but I probably did two calls. That may be 800 records total, but you are only downloading the content you need, not duplicating the Person record multiple times for all of the child records.

[@pierreplourde]

One thing missing that I was hoping would be covered is how to set up a many to many between people and addresses and between people and emails so that the linking tables get created, and how data crud would work with M:M.

[@vkumbaji2010]

Your content and delivery is simply great.. and easy to understand. Thank you so much for the wonderful tutorials.

[@peadenl]

Another great video Tim. I have limited experience with EF but you are 100% correct about how it will kill you in production. Also the developers will be clueless on how to fix it when you ask them why their application is running such idiotic queries. You have to try to fix issues by creating indexes and harass them to purge unnecessary data from the tables. Using stored procedures definitely provides the maximum flexibility in fixing the issues. I am going to check out Dapper based on your recommendation. Many thanks for outstanding work.

[@IAmTimCorey]

I am glad it was so helpful.

[@sukrusonar4613]

My English is not very well but I have learnt a lot of things and I just have watched the half of the video. Thank you Tim. (I am going to watch the half tomorrow.)

[@IAmTimCorey]

I am glad you have learned a lot from this video. Thank you for sharing.

[@alshafareen]

It's really a great video for a beginner who wants to refactor the existing application from any other platform to C# and EFCore. Thank you, Corey!

[@tomthelestaff-iamtimcorey7597]

Thanks for trusting Tim to help you build your skills.

[@asheeon]

Someone might've already posted so, but fun fact. If you enable C#8's Nullable Context for the whole project, EFC will automatically adapt to that. Making all model fields by default [Required], and only making them nullable if the type is a nullable type (like: string?) Thanks for the eye opening video, some of this stuff I had never thought about!

[@IAmTimCorey]

Thanks for sharing!

[@torrvic1156]

Really great advice! I had exactly this issue when I wanted to add some new fields to MS Identity table of users. I intended this fields (FirstName and LastName) to be optional but in the snapshot I saw that EF always made them obligatory. I tried to manually fix the migration before updating of the database but it failed and then I did exactly what you told and it totally helped.

[@codyjmathis]

Great information, Tim. Personal best practice is don’t use code first! Entity is great for help you quickly create class models and data access code but not for database creation. Thanks for all the great information as always!

[@IAmTimCorey]

Thanks for sharing!

[@AlaminHossainMAIN]

Finally. I have been seeing the Entity framework for over 6 years and never liked it. But all the tutorials about .net pushing me to work with the Entity framework. I know some of these issues about entity framework but your clear out more thing no one ever does. That's really are awesome.

[@IAmTimCorey]

Glad I could help!

[@BigBlueRabbit]

It's so useful and refreshing to receive an "opinionated" viewpoint on all these development tools. Personally I think Microsoft leave us in a state of confusion and "decision paralysis" when they present every tool as equal with no explanation or context. The value is that Tim's opinion is based on years of experience and real-world development. We don't have to agree with what he says, but we can appreciate the arguments. This channel is a great help when faced with making a decision for a large system that must run and evolve over years rather than be a quick, short-lasting solution. I hope you continue with your opinionated viewpoint ;-)

[@tomthelestaff-iamtimcorey7597]

Thanks for sharing that insightful perspective. Much appreciated.

[@gavranhas]

That was amazing, Tim. Thank you very much for all the work you have to put this explanation up.

[@IAmTimCorey]

You are welcome.

[@adam-xt8te]

1:46:50 What have I to do if I want to receive Person list with EmailAddressses list in each item? I used something like SELECT person.*, (select email.address from EmailAddresses as email where email.personId = person.Id for json path) as 'emailAddressesJSON' from Persons and deserialized result to emailAddresses list, but I suppose it can be done nicer. For json path isn't available in every sql engine, mssql has it only since 2016 edition

[@kaanacar8340]

Hi, How do we pull only the spesific columns from the related included table?

[@arpanmukherjee4625]

This video is a Goldmine for learning EF Core the right way.

[@IAmTimCorey]

Thanks!

[@Rexxior]

Thanks for the excellent video, it prompted me to try to limit length for my strings. But it turns out that Postgres doesn't have this nvchar(max) performance problem, it maps string to Text by default. When length has a limit, it maps to "character varying(x)". Postgres states that is no performance difference as they use the same underlying type. Limiting the length actually add extra check for length. Text is actually preferred type for Postgres. So unless it is a business requirement, setting max length doesn't help performance wise with Postgres.

[@upcsatx]

At 18:13 had to right click on db in server object explorer and choose "refresh" before right click-Properties. (otherwise no connection shows in properties page).

[@IAmTimCorey]

Interesting. Thanks for sharing.

[@zebcode]

The intro is great. You set the rules on ranting etc. I like that you're somewhat critical of EF. I actually like using EF but I want a balanced opinion. I'm really looking forward to this content.

[@IAmTimCorey]

Thanks! I am glad you appreciated it. I'm all for healthy debate. We just seem to have so little of it recently. I want to promote the right way to disagree and still respect each other.