@@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!
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: th-cam.com/video/ijDcHGxyqE4/w-d-xo.html
@@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
Small correction: Ascii has 256 characters Unicode has 143,859 characters Thank you Tim for your hardwork in putting these videos together. Greatly appreciated 🙏
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.
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.
I would like to provide some feedback: First, this has been a tremendously helpful video to me. You are absolutely correct, I followed a youtube tutorial and with entity framework got database access working. I, at the time, did not even consider best practices, just basked in the glory of pointing at a simple webpage with a working database connection. I get the vide you're approaching this video too much from the aspect of having a problem with bad practices becoming common place. I think this would be a much more helpful video if were a competing beginners tutorial of how to build a simple web app with a data base connection, *using* best practices. Then explain through the steps why these best practices are important. I am all self taught and no were near competent or proficient, so I'm relying heavily on a number of different tutorials and view points to try and form my own picture of asp. This is a tremendously helpful video, so thank you.
Thank you for the feedback. If you look through Tim's videos you will find several Beginner videos, where this one is intended more for someone more familiar with EF. Consider th-cam.com/video/WGbTM198-eA/w-d-xo.html for a basic app with database
@@tomthelestaff-iamtimcorey7597 I think you missed the point entirely. Tim complains about beginner videos using entity framework not using best practices. I'm talking about best practices, on a video about entity framework. So, how exactly does a link to a video that isn't about entity framework going to help me achieve best practices with entity framework? I concede I perhaps should have been more direct with my language, I erroniously assumed my comment was clear. Tim makes some valid observations but in my opinion draws the wrong conclusions. Entity Framework does an excellent job of making database connections accessible as well as reducing the total number of skillsets required to achieve desirable results. Tim also correctly points out, but misses the opportunity to address the short comings of tutorials that use entity framework without best practices. I have zero, I mean zero desire to learn SQL. So much so that my original plan for this project was to build it in a console app and use a csv to store my data. Just to avoid SQL. Entity Framework made the database accessible enough I'm now building my project as an asp.net mvc web application. I enjoy writing in C#, but try to avoid everything else.
I did cover best practices with Entity Framework in this video (avoiding ToList, watching joins, improving data types, and more). However, your end goal (use SQL without knowing SQL) is in itself a bad practice that I am advocating against. Entity Framework should not be a replacement for SQL knowledge. The fact that it is promoted as such is a REALLY BAD practice. As I demonstrated in this video, not knowing SQL means you don't understand why you are doing things. That means you cannot make the best decision for the specific situation you are in. Not knowing SQL means you cannot evaluate if your query is overly expensive or not. Not knowing SQL means when you get to production and have a problem with your database, you will be incapable of efficiently diagnosing and fixing the issue. I get that learning SQL is a whole skillset of its own, but understanding how your data is stored and retrieved is a massive part of your application. You need to do it right.
@@IAmTimCorey I do appreciate your position, however it's still missing the bigger picture. As right as you might be, as someone who was a very good mechanic, I fully appreciate how detrimental following bad practices can be. However, sometimes a tool that promotes bad practices is still too valuable to ignore. Entity Framework is easier to use. I'm hoping you'll be willing to see, at least from my perspective, that it's past the time of saying using Entity Framework in this way is bad practice, but rather, how to encourage Entity Framework development to improve on its weaknesses. I want to say I genuinely respect your opinion on the matter, but learning SQL queries is just a flat no go for me. I find it confusing and overwhelming. C# and VBA have been the only languages I haven't really struggled to learn. I'm atrocious with html, css is a complete mess... but my very first project in c# beyond the hello world tutorials was to build an enigma machine simulator that actually worked with other simulators. I don't know how to explain it, perhaps I'm such an outlier case that my opinion doesn't matter. I just see how good entity framework is for keeping consistency of code. I think there needs to be more videos like this one that improve the practices. Of the ten or fifteen different tutorials I've used, yours is the only one that points out things like specifying string length. I rewrote my project after watching this video to implement a number of the things I learned. So I hope my criticism comes off with the genuine appreciation that is due for the knowledge provided.
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.
@@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?
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!
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.
a bit long. managed to see it to the end at 3rd attempt only. but very interesting, especially 2nd part/half. lots of interesting hints. Спасибо very much, Tim.
Not sure if anyone answered this question, but to use EF Core without connecting to a frontend for dependency injection like in ASP.Net Core, just override the OnConfiguring() method when inheriting DbContext in People Context. That'll give you a local optionsBuilder to setup your database connection information etc .. then you can call it like a standard class.
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!
Good video! On the one to many part in building your model, I would use ICollection Addresses {get;set;} = new HashSet(); Also depending on the version of EFCore, you could use virtual for lazy loading. So you don't need to have this issue of pulling unnecessary data by default.
Thanks for sharing. What benefit will the HashSet provide? Also, have you profiled the lazy loading? I'm assuming it does a query for just the data it needs in real-time which would be more efficient (by far) but I'm not familiar with what the query looks like. Any idea?
@@IAmTimCorey It is an EF Code First modeling convention that specifies a one to many relationship and allows for lazy loading, i.e. loading the required data when first accessed. It is what will cause the creation of the index and the cascade delete. BTW, this is created in ctor. Emails = new HashSet(); If you'd like to have many to many relationship then both models need to have an ICollection of the dependant type. EF will then create a many to many join table of the Foreign Keys. if you have a one to one relationship then you should have public virtual of Type of the foreign key. So that it can be lazy-loaded if needed. That is, if I have public int SpouseId in my Person model then the model should have a public virtual Person Spouse property. To use EF correctly you need to learn EF Code First Conventions and honestly even if you use EF DB First you still should learn Code First conventions.
Thanks for the tutorial. Could you please show us a real example on how to configure it, if we have multi assemblies, and how to add the references without having circular dependencies then make database-migration? Thanks
I would say there is some misinformation at around the 27:00 minute mark. We have an api project that has layers like this: controller=>service=>repository and a shared layer that hosts the business objects. The entity framework context is in the repository layer, We do reference the context to configure dependency injection(not great) but nothing else leaks out of the repository layer all the configuration and migration stuff is done in the repository implementation project and its the only layer that uses the context. Also the business objects are in a project that does not know about entity framework.
That leakage was what I was talking about. It isn't the end of the world but it isn't ideal as the "suggested" solution - there are ways to eliminate the leakage but they aren't the default.
I completely agree with your overall assessment Tim, and is exactly why I have avoided EF over the years in favor of raw ADO.NET in projects that will see heavy use in production; Any time I ever saved up front with EF was heavily lost later on tracking down odd issues. I always create my database structure first before I write any code so that I'm focusing on database performance. My question is does the story significantly change with EF Core if you don't use the code-first strategy and mold the code around a database that has already been thought through? Meaning, will it generate more proper code if it can read from a pre-defined database rather than having to infer so much from C# classes? Always appreciate your insight.
Database first will eliminate the creation assumptions but it won't fix the performance of the queries. I would recommend you look at Dapper. It has the speed of ADO.NET (practically - there is a minuscule overhead) and it converts the data to objects correctly and safely: th-cam.com/video/Et2khGnrIqc/w-d-xo.html Also, check out SQL Server Data Tools in Visual Studio to make creating your databases easier: th-cam.com/video/ijDcHGxyqE4/w-d-xo.html
Oh, now I understand. In my "Kolleg" , C# is only taught with EF. I've been looking for videos that are compatible with that (for example for Rest Api calls). I already noticed, that I can't use your videos for that. You have many great tutorials, but now I know to skip the db-related stuff. (I'm sure Dapper is great, but I'll try to pass my classes first.)
@@IAmTimCorey but I have to say, your video was in many parts more in-depth than what our professor told us. We were shown how to optimize, but not the repercussions of not doing it. Now it all makes much more sense. I would love to see more of that.
To those who aren't aware, in EF Core you should use the EF.Functions.Like() method in your LINQ to get that functionality. If using PostgreSQL, use EF.Functions.ILike() for a case-insensitive version.
Hey Tim whenever I access data with efcore and it has a class in it like public class Music : DB { public string Title {get; set; } public Artist artist { get; set; } } If I save to artist during runtime it works on saving and retrieval but on a restart the artist key is always 0 until I save it again then it works until a restart. Music saves just fine tho Happens on everything even lists sqlite efcore 3 I'm not sure what's causing it Also thank you for the vids you've helped me a lot
There is a misunderstanding here of how EF Core was meant to be used. It does not aim to take SQL aware from the developer. You are still supposed to write compiled objects for that -- USPs and UDFs. No developer is sneaking through a career without SQL. The purpose of Core is to allow hosting on low cost servers. The purpose of EF is to remove dreary DAL-code writing. If any technology was supposed to allow you to sneak by without SQL, it would be LINQ. The strong point of LINQ is to let you play with some in-memory data. Next up, performance. You are not supposed to make LINQ do the heavy lifting that T-SQL is supposed to do. I use table returning functions for that because they are compiled. If there is a downfall, it's that EF Core doesn't necessarily know about the object coming back. For that, I temporarily allow the UDF to make a permanent table. Then I let the table sit there during a migrations command, and once I have the definition, I'm ready to go. This is kind of a pain when you have to change a column later, but still saves time and improves accuracy over handwritten DALs.
"No developer is sneaking through a career without SQL" - that is unfortunately a very naive statement. That is exactly what is happening. I've had to clean up multiple messes because of it. Ask a database administrator what they think of Entity Framework and you will get an earful. That isn't because EF is a horrible tool. It is an excellent tool, but it is often abused and used poorly. You are right in your statements, that EF Core wasn't meant to be a replacement for SQL knowledge and that LINQ wasn't meant to do the heavy lifting. However, that's exactly what is happening in a LOT of cases.
You are most welcome. As for the performance problems, mostly they are a result of not optimizing the C# code enough to make good database calls. I still prefer Dapper because it does not negatively impact performance on its own (your queries are either performant or they aren't but it is up to you).
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.
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.
I know SQL pretty well, but just started with C# about a month ago and i was going through a project that used Entity Framework. I remember going "yikes" when i went over to SSMS to check the tables created by EF and saw all of those nvarchar(max).
I feel the Raw Sql and Stored Procedures commands in the new EF Core will make Dapper less desirable unless you truly want a library with a small footprint, but you lose all the benefits of EF Core, including migrations, code first/scaffolding and much more efficient write commands which dapper is not much more efficient.
EF has always had the ability to write your own SQL or use stored procedures. The problem is that when you start doing that, you lose what gives EF its benefit. SSDT has migrations and code first still has the issues that this video covers. Beyond that, EF is basically the same as Dapper, so now you have a more expensive system that is slower that does practically the same thing.
@@IAmTimCorey Really appreciate your response.. I will have to look over the video again.. So, you really think the Sql commands in EF Core are much slower than Dapper? Wouldn't the ease of not having to write Update , Insert, Delete queries have some advantages with making code leaner? I find the big issue with micro ORMs is having to do so much repetitive SQL for update/write commands and the performance doesnt seem to be significantly better. Wouldn't the lack of extra code be an advantage, esp when it comes to debugging, code verbosity, dev time, etc? If EF Core is significantly slower with raw SQL reads that is a big case to still stick with Dapper. As far as migrations.. How could you handle migrations with a pure Dapper approach? Is there a way it could be done effectively?
Hey Tim, Is it ok if I added enum inside entity framework where statement ?? or it well behave like calling a function ?? someList.where (x => x.statuscode == (int)status.active) is this a bad way of filtering data
Hey Tim, love your stuff. I've been in a lot of software development environments, but none of them would be open to changing the database model from the coding environment. How would you change this approach if the database needs to be modified only in SQL Server (SSMS)?
Hi Tim, EF was the cause of issues in our company's systems. All our applications which mostly are medium scale, used EF which caused a hit in performance. So it took us 3 years to remove all EF instances on our systems and everything after that was like lightning! I think EF is only good for simple DB schemas and small systems with a few hundred , non-complicated tables and relationships. For medium to large scale, I wouldn't recommend it, certainly proven that it slowed our systems due to us having thousands of tables with complicated many-to-many relationships and foreign keys.
Yep. The square brackets indicate a list. Curly braces indicate an object. When you are sending one object to something that expects a list of objects, in C# we say "List". Similarly in JSON, we say "[{ myField: 'hi' }]"
Pls help, The project's target framework does not contain Entity Framework runtime assemblies. Please review the target framework information in the project's property page. after clicking ADO.NET Entity Data Model how to fix it
First of all thanks for making very good article i have found you very good in explanation of anything. I just wanted to knowone thing if we use procedure in all db interaction using EF does it will help in performance as well as less code and we have full control over what queries we have written
You can use stored procedures with EF and that is advisable in some of your queries in order to get the performance you need. However, if you are going to use stored procedures for all of them then you will be better off using Dapper for your commands since you aren't using the extras that EF provides anyway and you are getting the downsides.
Hi Tim, I was inspired by a lot of your videos so I created a demo project that encompassed a lot of different technologies. But the main goal was to demonstrate how I can get the same job done with EF core and Dapper to perform the same task. The project uses Generic Repositories, API versioning, Swagger, Autofac for DI, Automapper, Asp.net IdentityCore with JWT for Authentication which includes Claims as well as Role-based authorization. I was wondering if you would have the time to take a look at it and give me some feedback? I can upload it to Github.
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.
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!
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.
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.
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.
@@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.
@@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.
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.
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.
@@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.
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.
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.
@@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.
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.
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
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.
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.
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.
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.
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).
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.
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).
If I were going to use EF, I would use database first. However, I was demonstrating the challenges with the typical way EF is used (and taught), which is code first.
@@IAmTimCorey Thanks for the reply, I thought I was doing it wrong since nobody talks about db first. The video is very helpful, most of the times nobody checks after my code, so I have to look for best practices myself.
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.
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!
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?
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
@@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.
@@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
@@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).
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!
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.
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!"
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).
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.
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 ( th-cam.com/video/ijDcHGxyqE4/w-d-xo.html ) and then use Dapper for data access. It just depends on the situation, the team, etc.
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.
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!
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.
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 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.
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.
For today a little bit outdated, from version 5 we can use AsSplitQuery, and most of the problems disappears almost instantly, version 6 even much better. Regarding knowing SQL, I agree that is important to know SQL, but is very different to know SQL and to know where to identify problems, than to work on daily basis with SQL. I'm using EF core for more than 3 years and I can keep my apps running on production without any significant loss on performance, and at the other hand the ORM and migrations keep my environment safe , so every small change on schema/structure I MUST change my code everywhere is used, something that was part of my constants nightmares while I worked with SQL SP/Views years ago. I need to admit, that sometimes I need to rely on views with CTE or similar SQL specifics performance helps (indexed views). But in 99% cases is much easier to write and separate steps (and reuse) writing queries inside EF than directly SQL
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!👏👏👍👍
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!
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.
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.
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); }
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.
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!
The BIGGEST oversight that many people leave out is maintainability. Most applications do not have the NEED to be the most efficient. Unless you are a one-person team or you own the company, chances are you will be passing along the code to someone else. Will the the next person needs days or weeks to understand? Is that worth the extra work needed to improve the efficiency? Is the code/queries written in such a way that beginners can take it over without "screwing it up"? It is awesome if you can make your code more efficient but if no one else has the understanding or knowledge needed to move forward with what you have done, then your time spent to make it more efficient may have just been lost.
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
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!
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
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.
@@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.
@@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.
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.
EF is a 700 HP car but without ESP an no ABS. you need to be a real driver to master the beast. Those who say EF is slow realy need some more knowledge about it. I personaly have never used EF code first before, i'm way more comfortable with DB first, and i can assure you, the beast is realy fast. The things you need to be careful of are lazy loading and DbContext beeing disposed when it shouldn't. But as tim said, EF has all the tools you need, you can include relations manually and never think about DbContext again, but doing it the wrong way could make EF load the entire database in memory and that's realy bad, especialy with circular references.
The issue with the speed is the lack of really good configuration and an understanding of SQL and performance profiling. I think your analogy is spot on.
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
This videos seems quite prescriptive for “don’t use EF no matter the case” when in reality, the situation is more nuanced. If you want higher development velocity, Dapper is going to slow you down as you write repetitive boilerplate any time you change something. If you want higher performance, then you’re correct, maybe consider Dapper or even writing your own SQL layer for real time applications. But a blanket “EF core bad dapper good” response hides any nuance
You could create an EF repository project that implements an interface that your front end uses and just inject that, no? In that way your front end wouldn't necessarily need to know that you're using EF for data access
Came looking for this comment. A lot of the negative things, Tim mentions in the beginning, about UI project being mixed with the DB project, should be able to fixed as you suggest. The db connection string can be configured inside the context class, instead of Startup.cs, so there's nothing left in the UI project, other than knowing about the repo classes.
I like using EF and I am a senior developer. Perhaps I missed it but you can also write your own sql and execute it in EF for the more complex data queries where load is an issue. Why did you not address this as well?
Time, mainly. I did mention that you need to rework your queries for performance but with this video creeping up on two hours as it was, I just didn't have the time. At the end of the day, the main point was that you need to invest the time to learn EF REALLY well if you are going to use it in production. It isn't something you can just hope works well or casually use.
Okay around the 15 minute mark you start talking about how you can't set up EFCore without a front-end. I honestly don't know what you're talking about. I'm currently building an API using EFCore that has no front-end at all. Eventually I'll set it up like any other api and call it from a front-end web application. Also, my coworker at my previous job was using EFCore this way for the last two years, so it isn't something new. I'm not sure why I'm watching this video any more as it doesn't seem like you have any idea what you're doing. I'm embarrassed to see this video has 200k views. The front-end does not have to use EFCore. The front-end can be written in classic html, css and Javascript. For a better intro to EFCore apis, I used this one: www.udemy.com/course/net-core-31-web-api-entity-framework-core-jumpstart I got stuck on trying to do MORE than the course shows and so now I'm looking for more/other answers.
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.
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?
Hey Tim , great courses and great things I like end comparison of entityfamework with dapper by thier benefits, can you make another why to choose the entityframework upon nhibernate orm framework.
I have watched this whole Tutorial of yours and just wanted to know if you are going to make a video on optimising LINQ Queries in the best possible way. I've also watched some of your other tutorials and they are great. Good work keep going.
@@IAmTimCorey First of all thank you for replying it's hard to reply everyone since you have a big fan following in Software Development. And second I'm not a hater of ADO but I wanted to use simplicity of LINQ with optimized Queries if possible. Even though after using some tricks like AsNoTracking() I can speed up the Fetching Queries. I need more details in this particular domain if possible. Thank you so much once again for giving us such great tutorials.❤️
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!
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.
![CAMPปลิ้น | EP.82[1/2] แก๊ง 3 สาวเพื่อนซี้บุก CAMPปลิ้นครั้งนี้ห้ามเสียอาการ](http://i.ytimg.com/vi/_6WUjXHe1TM/mqdefault.jpg)
"If the way someone develops a C# application makes you angry, I suggest you reevaluate your priorities in life." LOL legend
lol thanks.
@@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!
I haven't found one I liked yet and I'm considering writing one.
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: th-cam.com/video/ijDcHGxyqE4/w-d-xo.html
@@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
Small correction:
Ascii has 256 characters
Unicode has 143,859 characters
Thank you Tim for your hardwork in putting these videos together. Greatly appreciated 🙏
And even smaller correction: ASCII is written in all capital letters.
@@akuskus that's not really a correction of data, just convention, OP actually gave a correction by providing new facts.
@@ahmedifhaam7266 true
small correction ASCII should be written in all capital
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.
Welcome back and thanks for trusting Tim for growing your skills.
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.
I am glad it was so helpful.
I would like to provide some feedback:
First, this has been a tremendously helpful video to me. You are absolutely correct, I followed a youtube tutorial and with entity framework got database access working. I, at the time, did not even consider best practices, just basked in the glory of pointing at a simple webpage with a working database connection.
I get the vide you're approaching this video too much from the aspect of having a problem with bad practices becoming common place. I think this would be a much more helpful video if were a competing beginners tutorial of how to build a simple web app with a data base connection, *using* best practices. Then explain through the steps why these best practices are important.
I am all self taught and no were near competent or proficient, so I'm relying heavily on a number of different tutorials and view points to try and form my own picture of asp. This is a tremendously helpful video, so thank you.
Thank you for the feedback. If you look through Tim's videos you will find several Beginner videos, where this one is intended more for someone more familiar with EF. Consider th-cam.com/video/WGbTM198-eA/w-d-xo.html for a basic app with database
@@tomthelestaff-iamtimcorey7597 I think you missed the point entirely. Tim complains about beginner videos using entity framework not using best practices. I'm talking about best practices, on a video about entity framework. So, how exactly does a link to a video that isn't about entity framework going to help me achieve best practices with entity framework? I concede I perhaps should have been more direct with my language, I erroniously assumed my comment was clear.
Tim makes some valid observations but in my opinion draws the wrong conclusions. Entity Framework does an excellent job of making database connections accessible as well as reducing the total number of skillsets required to achieve desirable results. Tim also correctly points out, but misses the opportunity to address the short comings of tutorials that use entity framework without best practices.
I have zero, I mean zero desire to learn SQL. So much so that my original plan for this project was to build it in a console app and use a csv to store my data. Just to avoid SQL. Entity Framework made the database accessible enough I'm now building my project as an asp.net mvc web application. I enjoy writing in C#, but try to avoid everything else.
I did cover best practices with Entity Framework in this video (avoiding ToList, watching joins, improving data types, and more). However, your end goal (use SQL without knowing SQL) is in itself a bad practice that I am advocating against. Entity Framework should not be a replacement for SQL knowledge. The fact that it is promoted as such is a REALLY BAD practice. As I demonstrated in this video, not knowing SQL means you don't understand why you are doing things. That means you cannot make the best decision for the specific situation you are in. Not knowing SQL means you cannot evaluate if your query is overly expensive or not. Not knowing SQL means when you get to production and have a problem with your database, you will be incapable of efficiently diagnosing and fixing the issue. I get that learning SQL is a whole skillset of its own, but understanding how your data is stored and retrieved is a massive part of your application. You need to do it right.
@@IAmTimCorey I do appreciate your position, however it's still missing the bigger picture. As right as you might be, as someone who was a very good mechanic, I fully appreciate how detrimental following bad practices can be.
However, sometimes a tool that promotes bad practices is still too valuable to ignore.
Entity Framework is easier to use.
I'm hoping you'll be willing to see, at least from my perspective, that it's past the time of saying using Entity Framework in this way is bad practice, but rather, how to encourage Entity Framework development to improve on its weaknesses.
I want to say I genuinely respect your opinion on the matter, but learning SQL queries is just a flat no go for me. I find it confusing and overwhelming. C# and VBA have been the only languages I haven't really struggled to learn. I'm atrocious with html, css is a complete mess... but my very first project in c# beyond the hello world tutorials was to build an enigma machine simulator that actually worked with other simulators.
I don't know how to explain it, perhaps I'm such an outlier case that my opinion doesn't matter. I just see how good entity framework is for keeping consistency of code. I think there needs to be more videos like this one that improve the practices. Of the ten or fifteen different tutorials I've used, yours is the only one that points out things like specifying string length. I rewrote my project after watching this video to implement a number of the things I learned. So I hope my criticism comes off with the genuine appreciation that is due for the knowledge provided.
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.
It has come a long way.
They have only five or six people working on the Entity Framework team. That is not very invested in my opinion.
@@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?
@@lenardbartha6722 : They said this themselves somewhere on their github pages where they were discussing what things to prioritize.
@@roodborstkalf9664 Hmm, that is good to know.
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!
Thank you!
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.
I loved the way you get to the detailed explanations!
Thank you!
a bit long. managed to see it to the end at 3rd attempt only. but very interesting, especially 2nd part/half. lots of interesting hints. Спасибо very much, Tim.
I am glad it was helpful.
Not sure if anyone answered this question, but to use EF Core without connecting to a frontend for dependency injection like in ASP.Net Core, just override the OnConfiguring() method when inheriting DbContext in People Context. That'll give you a local optionsBuilder to setup your database connection information etc .. then you can call it like a standard class.
Thanks for sharing.
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!
Just be sure to do the work needed to design the database well.
Good video! On the one to many part in building your model, I would use ICollection Addresses {get;set;} = new HashSet(); Also depending on the version of EFCore, you could use virtual for lazy loading. So you don't need to have this issue of pulling unnecessary data by default.
Thanks for sharing. What benefit will the HashSet provide? Also, have you profiled the lazy loading? I'm assuming it does a query for just the data it needs in real-time which would be more efficient (by far) but I'm not familiar with what the query looks like. Any idea?
@@IAmTimCorey It is an EF Code First modeling convention that specifies a one to many relationship and allows for lazy loading, i.e. loading the required data when first accessed. It is what will cause the creation of the index and the cascade delete. BTW, this is created in ctor. Emails = new HashSet();
If you'd like to have many to many relationship then both models need to have an ICollection of the dependant type. EF will then create a many to many join table of the Foreign Keys.
if you have a one to one relationship then you should have public virtual of Type of the foreign key. So that it can be lazy-loaded if needed. That is, if I have public int SpouseId in my Person model then the model should have a public virtual Person Spouse property.
To use EF correctly you need to learn EF Code First Conventions and honestly even if you use EF DB First you still should learn Code First conventions.
Probably the best EF video I watched
Thank you!
Thanks for the tutorial.
Could you please show us a real example on how to configure it, if we have multi assemblies, and how to add the references without having circular dependencies then make database-migration? Thanks
I would say there is some misinformation at around the 27:00 minute mark. We have an api project that has layers like this:
controller=>service=>repository
and a shared layer that hosts the business objects. The entity framework context is in the repository layer, We do reference the context to configure dependency injection(not great) but nothing else leaks out of the repository layer all the configuration and migration stuff is done in the repository implementation project and its the only layer that uses the context. Also the business objects are in a project that does not know about entity framework.
That leakage was what I was talking about. It isn't the end of the world but it isn't ideal as the "suggested" solution - there are ways to eliminate the leakage but they aren't the default.
I completely agree with your overall assessment Tim, and is exactly why I have avoided EF over the years in favor of raw ADO.NET in projects that will see heavy use in production; Any time I ever saved up front with EF was heavily lost later on tracking down odd issues. I always create my database structure first before I write any code so that I'm focusing on database performance. My question is does the story significantly change with EF Core if you don't use the code-first strategy and mold the code around a database that has already been thought through? Meaning, will it generate more proper code if it can read from a pre-defined database rather than having to infer so much from C# classes? Always appreciate your insight.
Database first will eliminate the creation assumptions but it won't fix the performance of the queries. I would recommend you look at Dapper. It has the speed of ADO.NET (practically - there is a minuscule overhead) and it converts the data to objects correctly and safely: th-cam.com/video/Et2khGnrIqc/w-d-xo.html Also, check out SQL Server Data Tools in Visual Studio to make creating your databases easier: th-cam.com/video/ijDcHGxyqE4/w-d-xo.html
Oh, now I understand. In my "Kolleg" , C# is only taught with EF. I've been looking for videos that are compatible with that (for example for Rest Api calls). I already noticed, that I can't use your videos for that.
You have many great tutorials, but now I know to skip the db-related stuff. (I'm sure Dapper is great, but I'll try to pass my classes first.)
Definitely try to pass your class first. 😉
@@IAmTimCorey trying my best. 😉
@@IAmTimCorey but I have to say, your video was in many parts more in-depth than what our professor told us. We were shown how to optimize, but not the repercussions of not doing it. Now it all makes much more sense.
I would love to see more of that.
To those who aren't aware, in EF Core you should use the EF.Functions.Like() method in your LINQ to get that functionality. If using PostgreSQL, use EF.Functions.ILike() for a case-insensitive version.
Great Tip, thanks for sharing Christoban.
Hey Tim whenever I access data with efcore and it has a class in it like
public class Music : DB
{
public string Title {get; set; }
public Artist artist { get; set; }
}
If I save to artist during runtime it works on saving and retrieval but on a restart the artist key is always 0 until I save it again then it works until a restart.
Music saves just fine tho
Happens on everything even lists sqlite efcore 3
I'm not sure what's causing it
Also thank you for the vids you've helped me a lot
That's odd. I'm not sure why that is happening (but I'm no EF expert).
@@IAmTimCorey the data gets saves to the DB and the key is written but on restart when I try to access it the Id becomes 0
Tim: "I have some issues with EF"
Me: "waaaaaaat???"
[watches video]
Me: "yep... yep... agreed... yep...yep. Ok, I have issues with EF too"
lol
Glad I watched this. Had the impression you did not like/use EF. Also learned somethings!
Like or dislike, it still has lots of benefits!
There is a misunderstanding here of how EF Core was meant to be used. It does not aim to take SQL aware from the developer. You are still supposed to write compiled objects for that -- USPs and UDFs. No developer is sneaking through a career without SQL. The purpose of Core is to allow hosting on low cost servers. The purpose of EF is to remove dreary DAL-code writing. If any technology was supposed to allow you to sneak by without SQL, it would be LINQ. The strong point of LINQ is to let you play with some in-memory data. Next up, performance. You are not supposed to make LINQ do the heavy lifting that T-SQL is supposed to do. I use table returning functions for that because they are compiled. If there is a downfall, it's that EF Core doesn't necessarily know about the object coming back. For that, I temporarily allow the UDF to make a permanent table. Then I let the table sit there during a migrations command, and once I have the definition, I'm ready to go. This is kind of a pain when you have to change a column later, but still saves time and improves accuracy over handwritten DALs.
"No developer is sneaking through a career without SQL" - that is unfortunately a very naive statement. That is exactly what is happening. I've had to clean up multiple messes because of it. Ask a database administrator what they think of Entity Framework and you will get an earful. That isn't because EF is a horrible tool. It is an excellent tool, but it is often abused and used poorly. You are right in your statements, that EF Core wasn't meant to be a replacement for SQL knowledge and that LINQ wasn't meant to do the heavy lifting. However, that's exactly what is happening in a LOT of cases.
Thank you so much for your kind effort ❤️ Love from IRAQ ....
and please let use know if some of EF problem in performance get better thanks again .
You are most welcome. As for the performance problems, mostly they are a result of not optimizing the C# code enough to make good database calls. I still prefer Dapper because it does not negatively impact performance on its own (your queries are either performant or they aren't but it is up to you).
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.
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.
I know SQL pretty well, but just started with C# about a month ago and i was going through a project that used Entity Framework. I remember going "yikes" when i went over to SSMS to check the tables created by EF and saw all of those nvarchar(max).
Yeah, there are a lot of things to get right to get the end result you want.
This is Gold ❤️ Thanks Tim .
You are welcome.
I feel the Raw Sql and Stored Procedures commands in the new EF Core will make Dapper less desirable unless you truly want a library with a small footprint, but you lose all the benefits of EF Core, including migrations, code first/scaffolding and much more efficient write commands which dapper is not much more efficient.
EF has always had the ability to write your own SQL or use stored procedures. The problem is that when you start doing that, you lose what gives EF its benefit. SSDT has migrations and code first still has the issues that this video covers. Beyond that, EF is basically the same as Dapper, so now you have a more expensive system that is slower that does practically the same thing.
@@IAmTimCorey Really appreciate your response.. I will have to look over the video again.. So, you really think the Sql commands in EF Core are much slower than Dapper? Wouldn't the ease of not having to write Update , Insert, Delete queries have some advantages with making code leaner? I find the big issue with micro ORMs is having to do so much repetitive SQL for update/write commands and the performance doesnt seem to be significantly better. Wouldn't the lack of extra code be an advantage, esp when it comes to debugging, code verbosity, dev time, etc?
If EF Core is significantly slower with raw SQL reads that is a big case to still stick with Dapper.
As far as migrations.. How could you handle migrations with a pure Dapper approach? Is there a way it could be done effectively?
Huge Respect !
Thank you!
Thank you sir for sharing. This is a great content
You are welcome.
Did you use a tool for the generated json? That would be extremely useful!
FYI: As a former assembly programmer, I have to say that 1 byte = 0-255, and 2 bytes = 0-65535. Just sayin'.
lol yeah, teaches me for trying to say that without pausing to think.
Hey Tim, Is it ok if I added enum inside entity framework where statement ?? or it well behave like calling a function ??
someList.where (x => x.statuscode == (int)status.active) is this a bad way of filtering data
Hey Tim, love your stuff.
I've been in a lot of software development environments, but none of them would be open to changing the database model from the coding environment. How would you change this approach if the database needs to be modified only in SQL Server (SSMS)?
The scripts don’t have to be run from code you can export them and such… (I’m not an EF fan myself) but you can “operationalize” it.
Hi Tim, EF was the cause of issues in our company's systems. All our applications which mostly are medium scale, used EF which caused a hit in performance. So it took us 3 years to remove all EF instances on our systems and everything after that was like lightning! I think EF is only good for simple DB schemas and small systems with a few hundred , non-complicated tables and relationships. For medium to large scale, I wouldn't recommend it, certainly proven that it slowed our systems due to us having thousands of tables with complicated many-to-many relationships and foreign keys.
Thanks for sharing that from your real world experiences.
Thanks! This is an excellent lecture!
You are welcome.
If someone was having the same dumb problem as me on serialize, don't forget your square brackets and the beginning and the end of the json file...
Thanks for sharing.
@@IAmTimCorey I'm guessing it's because it accepted a list and I didn't send a list in json right?
Yep. The square brackets indicate a list. Curly braces indicate an object. When you are sending one object to something that expects a list of objects, in C# we say "List". Similarly in JSON, we say "[{ myField: 'hi' }]"
Pls help,
The project's target framework does not contain Entity Framework runtime assemblies. Please review the target framework information in the project's property page.
after clicking ADO.NET Entity Data Model
how to fix it
First of all thanks for making very good article i have found you very good in explanation of anything.
I just wanted to knowone thing if we use procedure in all db interaction using EF does it will help in performance as well as less code and we have full control over what queries we have written
You can use stored procedures with EF and that is advisable in some of your queries in order to get the performance you need. However, if you are going to use stored procedures for all of them then you will be better off using Dapper for your commands since you aren't using the extras that EF provides anyway and you are getting the downsides.
Thanks for your response. I also agree with you.
Hi Tim, I was inspired by a lot of your videos so I created a demo project that encompassed a lot of different technologies. But the main goal was to demonstrate how I can get the same job done with EF core and Dapper to perform the same task. The project uses Generic Repositories, API versioning, Swagger, Autofac for DI, Automapper, Asp.net IdentityCore with JWT for Authentication which includes Claims as well as Role-based authorization. I was wondering if you would have the time to take a look at it and give me some feedback? I can upload it to Github.
Unfortunately, I don't have time to review repos. I'm quite busy just replying to comments and emails. Sorry.
@@IAmTimCorey Thank you anyway for all the great tutorials.
What a video. 👏🏻👏🏻
Thanks!
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.
I am glad it was so helpful.
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!
You are most welcome. Thanks for the encouragement.
Mr.Tim Corey, your courses are superb educational and great resources for learners of all expertise levels.
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.
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.
I have the same opinion as you. In my company it looks the same as you explained. We never used code-first model.
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.
@@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.
@@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.
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.
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.
@@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.
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.
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.
@@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.
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.
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
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.
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.
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.
I try to be thorough in everything I teach. It is all about being real-world ready.
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.
Awesome!
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).
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.
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).
Why not develop database first using reverse engineering? I find it way easier having control of tables from mssql than be auto generated.
If I were going to use EF, I would use database first. However, I was demonstrating the challenges with the typical way EF is used (and taught), which is code first.
@@IAmTimCorey Thanks for the reply, I thought I was doing it wrong since nobody talks about db first. The video is very helpful, most of the times nobody checks after my code, so I have to look for best practices myself.
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.
Yes, there are many techniques that can do that.
Thanks for sharing the tip!
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!
Yeah, I just touched on some of the topics. There is a lot to cover. I'm glad you enjoyed the video.
Great points. Select solves the issues of include
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?
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
@@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.
@@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
@@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).
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!
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.
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!"
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).
You are the best programming teacher I've ever met. Thank you so much for this content.
Thank you!
you can use Iqueryable method for where clause, like predicatebuilder that is functional and also it is easy to use
Can you show me an example of what you mean? I'm not quite understanding what you are saying.
@@IAmTimCorey I would change the return type of the ApprovedAge method from bool to Expression and return x => x.Age >= 18 && x.Age
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?
This video is so detailed and thorough it shouldn't even be free
Thanks!
No it should not be free.
@@UnknownMoses i mean im quite happy is free
Totally agree with you
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.
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 ( th-cam.com/video/ijDcHGxyqE4/w-d-xo.html ) and then use Dapper for data access. It just depends on the situation, the team, etc.
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.
Thanks for sharing.
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!
Thank you!
Hummmm, in my whole development life this is the first time to see this type amazing explanation. Great job.
Thank you!
@@IAmTimCorey now you are our instructor, I have learned much techniques from your best tutorials.
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.
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.
Thanks for sharing.
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 !
You are welcome.
This One lecture is better then my half semester in uni. Thank you so much for your kind effort ❤️ Love from #Pakistan
You are most welcome. Thanks for watching.
@@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.
Thank you for this great tutorial. Cleared a lots of doubts I had.
Excellent!
1:14:30 instead of .Count() == 0 it's better use .Any().
Why? The SQL command it runs is the most efficient command it can run. Is there a different benefit?
@@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.
Ah, gotcha. Thanks for sharing!
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
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.
Man! your videos always have fully explained satisfying answers to my questions. Keep up the good work
Thank you!
For today a little bit outdated, from version 5 we can use AsSplitQuery, and most of the problems disappears almost instantly, version 6 even much better.
Regarding knowing SQL, I agree that is important to know SQL, but is very different to know SQL and to know where to identify problems, than to work on daily basis with SQL.
I'm using EF core for more than 3 years and I can keep my apps running on production without any significant loss on performance, and at the other hand the ORM and migrations keep my environment safe , so every small change on schema/structure I MUST change my code everywhere is used, something that was part of my constants nightmares while I worked with SQL SP/Views years ago.
I need to admit, that sometimes I need to rely on views with CTE or similar SQL specifics performance helps (indexed views). But in 99% cases is much easier to write and separate steps (and reuse) writing queries inside EF than directly SQL
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!👏👏👍👍
Thank you. That's what I attempt to do with all of my videos.
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!
Thanks!
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.
Yeah, it is just a pain to do so.
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.
Yep, pretty much.
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.
Thanks!
I find that data annotations are essential for getting more control on creating a model and they are easy to understand
That's good.
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);
}
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.
Aliaksandr Bortnik I quite agree with you there, Fluent is very useful in that situation
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!
Excellent!
The BIGGEST oversight that many people leave out is maintainability. Most applications do not have the NEED to be the most efficient.
Unless you are a one-person team or you own the company, chances are you will be passing along the code to someone else.
Will the the next person needs days or weeks to understand? Is that worth the extra work needed to improve the efficiency?
Is the code/queries written in such a way that beginners can take it over without "screwing it up"?
It is awesome if you can make your code more efficient but if no one else has the understanding or knowledge needed to move forward with what you have done, then your time spent to make it more efficient may have just been lost.
Really well made and I love how you show the simple things that are so often missed.
Thanks!
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
I will add it to the list. Thanks for the suggestion.
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
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!
Glad you like them!
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
Excellent!
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.
@@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.
@@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.
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.
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.
Well i used to do explicit loading to solve it , don't really know if they have such feature
thank you bro
Simple, clear, easy to follow lesson on this important topic.
Thank you!
EF is a 700 HP car but without ESP an no ABS. you need to be a real driver to master the beast.
Those who say EF is slow realy need some more knowledge about it. I personaly have never used EF code first before, i'm way more comfortable with DB first, and i can assure you, the beast is realy fast. The things you need to be careful of are lazy loading and DbContext beeing disposed when it shouldn't. But as tim said, EF has all the tools you need, you can include relations manually and never think about DbContext again, but doing it the wrong way could make EF load the entire database in memory and that's realy bad, especialy with circular references.
The issue with the speed is the lack of really good configuration and an understanding of SQL and performance profiling. I think your analogy is spot on.
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
Thanks
This videos seems quite prescriptive for “don’t use EF no matter the case” when in reality, the situation is more nuanced. If you want higher development velocity, Dapper is going to slow you down as you write repetitive boilerplate any time you change something. If you want higher performance, then you’re correct, maybe consider Dapper or even writing your own SQL layer for real time applications. But a blanket “EF core bad dapper good” response hides any nuance
I said over and over in this video that EF is a great product. The key is that you need to be an advanced user to safely use it.
You could create an EF repository project that implements an interface that your front end uses and just inject that, no? In that way your front end wouldn't necessarily need to know that you're using EF for data access
Came looking for this comment. A lot of the negative things, Tim mentions in the beginning, about UI project being mixed with the DB project, should be able to fixed as you suggest. The db connection string can be configured inside the context class, instead of Startup.cs, so there's nothing left in the UI project, other than knowing about the repo classes.
I like using EF and I am a senior developer. Perhaps I missed it but you can also write your own sql and execute it in EF for the more complex data queries where load is an issue. Why did you not address this as well?
Time, mainly. I did mention that you need to rework your queries for performance but with this video creeping up on two hours as it was, I just didn't have the time. At the end of the day, the main point was that you need to invest the time to learn EF REALLY well if you are going to use it in production. It isn't something you can just hope works well or casually use.
Okay around the 15 minute mark you start talking about how you can't set up EFCore without a front-end. I honestly don't know what you're talking about. I'm currently building an API using EFCore that has no front-end at all. Eventually I'll set it up like any other api and call it from a front-end web application. Also, my coworker at my previous job was using EFCore this way for the last two years, so it isn't something new. I'm not sure why I'm watching this video any more as it doesn't seem like you have any idea what you're doing. I'm embarrassed to see this video has 200k views.
The front-end does not have to use EFCore. The front-end can be written in classic html, css and Javascript.
For a better intro to EFCore apis, I used this one: www.udemy.com/course/net-core-31-web-api-entity-framework-core-jumpstart I got stuck on trying to do MORE than the course shows and so now I'm looking for more/other answers.
An API is a front-end. It isn't a GUI, but that doesn't mean it isn't a front-end.
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.
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. :)
You are welcome.
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?
Hey Tim , great courses and great things I like end comparison of entityfamework with dapper by thier benefits, can you make another why to choose the entityframework upon nhibernate orm framework.
Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/
I have watched this whole Tutorial of yours and just wanted to know if you are going to make a video on optimising LINQ Queries in the best possible way.
I've also watched some of your other tutorials and they are great. Good work keep going.
I will add it to the list. Thanks for the suggestion.
@@IAmTimCorey First of all thank you for replying it's hard to reply everyone since you have a big fan following in Software Development.
And second I'm not a hater of ADO but I wanted to use simplicity of LINQ with optimized Queries if possible. Even though after using some tricks like AsNoTracking() I can speed up the Fetching Queries. I need more details in this particular domain if possible.
Thank you so much once again for giving us such great tutorials.❤️
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!
Great!
Hi Tim Corey, Thanks For This video, I am from Uzbekistan and i am your student!
You are best teacher.
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.
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!
"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.
lol, glad you enjoyed it.
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.
Yep, that is a possibility.