Man, there are hundreds of videos on “how to EF”, and that’s fine. But your walkthrough here that included not only that, but also the pitfalls, what could cause problems, and WHY those can be problems was extremely helpful. The section explaining the string fields like NVARCHAR(MAX) was very informative and helpful.
@@IAmTimCorey 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: ruclips.net/video/ijDcHGxyqE4/видео.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
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!
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 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.
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!
While I didn't know about this channel, when I was trying to write migrations from other channels, no one went that deep, they didn't show the errors, and so I had a problem every time I found a problem myself. in the end, I lost my enthusiasm and instead of writing with migration, I switched to writing db first. when I discovered this channel, everything was great. Thanks
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.
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.
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!
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!👏👏👍👍
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!
Small correction: Ascii has 256 characters Unicode has 143,859 characters Thank you Tim for your hardwork in putting these videos together. Greatly appreciated 🙏
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!
What I love about this video is that you explain each topic with the right level of detail and in a succint and informative manner. Even someone who has primarly used Dapper loved the content and learned a lot.
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!
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.
Hey Tim, your content not only helped me to understand code and program, but also helped me to see the problems in a completely simple way. Your way of teaching and talking out the solution is unique & simple. Thanks for that.😀
I've been looking a lot of ef guides. I also have prior experience with it but never created a project from scratch myself, this guide is absolutely the best one I've found so far. Superb job and the flow you have is absolutelt great! Thanks a lot you saved me a lot of research time
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!
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.
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.
Another Awesome real world explanation. Even the preamble with the ground rules on commenting and disclaimer that everyone can have a valid opinion - priceless! Fortunately, it looks like I’m coming to the party at just the right time for .NET and learning C#. I’m working on a transition with a friend from a PowerBuilder based product to work through what makes sense to move to C# and .NET Core (for the computational / Data crunching part of the solution). You’re content has rapidly gotten me oriented and confident about iterating through a solution. Thank you again! -even more: You’re example right at the start is a Person with multiple addresses and emails - Real World requirement - and an explanation that communicates and causes the viewer to “think” but still simple enough to keep engagement. Wow!
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!
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).
Someone might've already posted so, but fun fact. If you enable C#8's Nullable Context for the whole project, EFC will automatically adapt to that. Making all model fields by default [Required], and only making them nullable if the type is a nullable type (like: string?) Thanks for the eye opening video, some of this stuff I had never thought about!
Really great advice! I had exactly this issue when I wanted to add some new fields to MS Identity table of users. I intended this fields (FirstName and LastName) to be optional but in the snapshot I saw that EF always made them obligatory. I tried to manually fix the migration before updating of the database but it failed and then I did exactly what you told and it totally helped.
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.
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.
Thanks Tim! I wish I had this a couple years ago to share with my junior developers. I have had the same reservations as you for many years about ORMs in general. I have seen them totally derail an application once it hit production. My team used EF for the first time a couple years ago and I have been fairly happy with it, but this video pretty much sums up my feelings about it. As a hiring manager, it has been a challenge to find newer developers that can work "without the net" of an ORM. I believe that knowing how to do both is critical to being an experienced developer.
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.
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.
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.
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 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.
A video of this quality is rare - thank you so much for this. I also learnt a lot from it. Well constructed and very clear. Thanks for covering some of the pitfalls and nuances. :)
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.
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 ( ruclips.net/video/ijDcHGxyqE4/видео.html ) and then use Dapper for data access. It just depends on the situation, the team, etc.
I understand what you mean at @15:30 about feeling weird with the Web project knowing about EntityFramework. The way I solve this is by creating a extension method in the DataAccess project (we'll call it .AddDataAccess(this IServiceCollection services) ), and then inside of this method I wire-up the .AddDbContext(). Finally, in the web project, you can simply call services.AddDataAccess() inside of the ConfigureServices, and the web project doesn't need to know anything about EntityFramework. Works great. Thanks for all of your videos!
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 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?
@@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.
Another great video Tim. I have limited experience with EF but you are 100% correct about how it will kill you in production. Also the developers will be clueless on how to fix it when you ask them why their application is running such idiotic queries. You have to try to fix issues by creating indexes and harass them to purge unnecessary data from the tables. Using stored procedures definitely provides the maximum flexibility in fixing the issues. I am going to check out Dapper based on your recommendation. Many thanks for outstanding work.
Wow, this is really informative. You are correct that EF is really easy to use with many amazing query tools, code-first migration and etc. It is one of my favorite backend framework when I do project. However, I have got interned in one company that uses EF, we faced some issue with EF and some of them is what you mentioned in the video. It was years ago, we were using .net core 2.1 at that time. I am not working with them anymore, but I heard that they ended up rewrite partial of the project to optimize it. This video taught me a lot, thank you very much!!
Great information, Tim. Personal best practice is don’t use code first! Entity is great for help you quickly create class models and data access code but not for database creation. Thanks for all the great information as always!
Thanks for the video. You smashed it. You showed key points in terms of performance, diagnostic, debugging and others. However, I disagree in these points: 1 - if an inexperienced developer write a Data Access layer using dapper the consequences could be (IMO) 10x worse than using EF as an inexperienced developer. First, most of the time they (inexperienced devs) will handle the connection by themselves ( handling transactions, open-close dB , etc) they will create the UoW and Repo, they will do simple queries that maybe (I’m almost sure) will be not more performing than the EF ones, the data access layer will be not as tested and documented as EF, they will spent more time due to creation of all the data access layer, and more. Thus, if we compare what you can achieve as an inexperienced developer using both of the tools, I would argue that using EF can be less harmful and more efficient, than an inexperienced developer trying to create their own custom ORM or Data access Layer. 2 - In most companies there are developer team and database team. In my view devs would relegate the migration/maintenance/performance of the DB to the dB team and would work together when changes impact both sides. 3 - Premature optimisation is the root of all evil 👿. I would focus at the beginning in achieving then when performance issue are identified (hopefully, performance, loading, peek testing are done) then I would optimise the bit that cause a bottleneck (this should be done by someone with experience though) 4 - The learning curve is shorter using EF. Most .net developers will learn C# and then will learn some SQL. You could start delivering or producing work with only knowing C# and lambda expressions. However, I believe that we need more videos as the one you did, as they show a view on both worlds (C# - SQL Server) and of course learn sql as much as possible. 5 - I would consider to explain how you could change from SQL Server to another database vendor, using Dapper/EF and also would talk about how to change completely or handle different DB vendor. Cases: 1 Imagine I change the code to use only MySQL. 2 - Imagine I deploy you client with different database, ex Oracle, MySQL, Postgre DB. What would happen, what need to be done, how Dapper vs EF core or EF 6 would handle that, is that even possible or is the kind of things that you need to tell to your clients to f... up? Other than that, I love the video and I learnt lots of it. Thanks 🙏🏼
1. I definitely think that you need to understand what you are doing before you write a data access layer (regardless of Dapper or EF). I do think that it is easier to make something without knowing anything if you are using EF. That's my issue. 2. I agree that this is ideal. If you do have two teams, why are you using code first EF? Dapper seems the more segmented and easier to keep performant route. 3. I would say that this phrase is the cause of a lot of the evils. There is a difference between premature optimization and writing good code. If you architect your application in a way that is inefficient, it will take a lot of rearchitecting to optimize it later. This introduces more bugs and causes more issues. 4. I would disagree that the learning curve of EF is shorter. It appears shorter but that is deceptive, as I demonstrated in this video. You think you understand what is going on until you hit production and it blows up. I had a lot of people tell me I should have just lazy-loaded my data and then everything would be good. That only works if you aren't doing a large display of your data (datagrid, etc.) If you do, then you actually made the problem worse. If you use EF, you NEED to understand SQL well to do it right. In a lot of cases, you might actually need to learn SQL better than if you were just using Dapper. If you just learn the C# side of things, you won't understand what is optimized and what is not. 5. My C# Application from Start to Finish course does replace the SQL connection (Dapper) with a custom text file system for data access. I also use pretty much the same Dapper code for SQL, MySQL, SQLite, and more in my various videos. I like the idea of showing how to swap out though.
4 года назад
IAmTimCorey thanks for answering. I really appreciate that you took time to read and reply my comment.
Just finished migrating from ef core to dapper best decision I've made, in dapper we are pulling paged data in milliseconds compared to at least a second on ef core,also your redis tutorial helped a lot with faster response 😃
This is such a great roundup, taken from the point of view of using EF and diving into the beginning and continued maintenance and improvement of the application, and then going over how it doesn't fulfill its promises. I try very hard to avoid being that grumpy old dev who says "just learn SQL" but as you've pointed out, you need to end up knowing it anyways. And SQL is such a fine domain specific language for relational databases that it seems like all you're doing is learning this abstraction in between the concrete need to know and use SQL anyways.
@@IAmTimCorey Hanging in there... can't wait to see you again at an event. I'm a fan of your work. I keep up with C# thanks to you and I really appreciated this thoughtful dive into EF with an objective yet skeptical point of view. Every time I think there is something more to teach I realize it's covered at IAmTimCorey... no joke...
Love when you said " I know I'm getting a Lot into SQL here"... Well thats the thing, if You want to use SQL without ADO you still need to know how EF uses SQL underneath. Great content, marvelous execution, superb knowledge.
Hey Tim. I’m only 28 minutes in and I’ve been using EF for years. I’ve been using the tooling, and not really understanding why, like ‘okay, this tutorial says I have to put EF in with my web stuff’ and it’s never felt right, but i’ve just gone ahead and done it, you’re the ONLY person who has validated my inner concern, I’ve never expressed it because it was just a wrong feeling. Also, where you say you need to know a lot of the advanced EF stuff, I 100% agree. EF is so quick and easy you just start using it, it’s when you really start to use it, you can find yourself going down a rabbit hole and not understanding. Sorry, one last point. I would, from experience like to mention that you really should understand SQL even just a little when using Linq and EF. I knew nothing when I started and EF and Linq made me lazy about learning SQL. I’m still no expert on SQL but getting better. Thanks for your tutorials, you really give real world examples and explanations which, in many occasions it’s a light bulb moment. Thank you
As someone who is learning c# for work and who is generally framework averse because of just how much they typically do for you, thanks for the excruciating detail. very very helpful
The intro is great. You set the rules on ranting etc. I like that you're somewhat critical of EF. I actually like using EF but I want a balanced opinion. I'm really looking forward to this content.
Thanks! I am glad you appreciated it. I'm all for healthy debate. We just seem to have so little of it recently. I want to promote the right way to disagree and still respect each other.
Wow, this is an amazing video! We were taught to use EntityFramework Core at my university, but they did not mention ANY of these huge drawbacks and how to overcome them.
Hi Tim, thanks for these videos, they are really good. However a minor correction to some of your data type comments -- ASCII has only 127 chars, later extended to 255 chars, whereas UNICODE has 65,535 chars, later extended to ~138k chars. Also I would argue that decorating entity primitive properties with DataAnnotations is not 'optimization' but a necessary part of your model specification, just as much as adding the properties to the entity in the first place. Of course EF code-first cannot generate a sensible data schema until it is provided with this information. MS documentation makes this clear too. I agree with you on annotating with SQL-specific DB types like "varchar" though. That is far from ideal, and could even be breaking with future SQL Server updates etc. It is possible that there is an alternative sensible annotation that lets you specify a character set or text encoding type instead, which would be a much better way of achieving the same result.
Yeah, slip of the tongue there. As for entity decoration being necessary, I agree but that isn't something that is required or necessarily taught right away. That's what I'm indicating is dangerous. Out of the box, if you use EF without a much deeper knowledge, you cause problems. At the end of the day, some of the benefits that EF is sold on are disingenuous, since we have to do more work then we are told.
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.
Hi Tim, thanks for the video! I don't like the code first approach just the same reason you demoed in the video. So in our projects, we use db first. And we do the revision control though the scripts, similar like flyway. I am glad that we avoided most of the pitfalls in the video. I think the benefit of EFCore is that after you knowing how EFCore works (although you might spend some time to learn), it's quite productive, and since it's ORM, it can keep the code base quite clean (again, we don't use code first:) this is important). Although dapper also has things like simpleCRUD, but you need do more stuff when handling for example, many to many scenario. In conclusion, learn EFCore well then it will be quite benefit. Thanks!
It all depends on where you want to do the work. I'd rather write a SQL script rather than verifying the design of each query and the performance implications of it.
It is 100% true that scaling a SaaS app used by a lot of users takes more or same knowledge of SQL when using an ORM (be it Hibernate in Java, ActiveRecord in Rails, dj-orm in Django or Ef Core in C#) than you would if you wrote SQL directly. Every big app that I worked on, ultimately rewrote performance critical pieces using direct SQL queries at some point. Plus, using ORM it's very easy to write bad code. For example, no one would purposely put an SQL query inside a loop when writing raw. However, your ORM code making magic queries to fetch associations lazily, is harder to see when written inside a loop causing N+1. I have spent an entire year, fighting bad cases of N+1 and still wasn't able to solve all of them because of how fancy Object Oriented design was made. Seriously, respect the DB operations when making a DB bound app.
Finally. I have been seeing the Entity framework for over 6 years and never liked it. But all the tutorials about .net pushing me to work with the Entity framework. I know some of these issues about entity framework but your clear out more thing no one ever does. That's really are awesome.
went through the whole video and do along with it. I'm deciding whether use Dapper or EF Core in this moment, the deep analysis made a long video never felt long, all information is really valuable. thank you!
Hey Tim, i would like to thank you personally because you have done great video work...I really understand everything that you explain in video. I have just started a few months ago a coding bootcamp and your videos are extremely helpful. Well done. I wish you everything best!!!!
Hi Tim, First of all thank you for this video and for all videos posted on your channel. All very reliable content. I watched your video because I asked a company to rewrite for Windows platform an old application I inherited. They came back with a windows forms, C# and EF solution. I am now in charge of the maintenance of the application and as DB designer and with very good knowledge of SQL I am always skeptical with all these frameworks. In past life I was also maintaining a Java/hibernate web site. I must admit that EF seems to generate a correct SQL query than hibernate 5 years ago ( perhaps it has improve since then). To be noted that the database is well normalized, not fully obviously. So as a DB manager I am sometime frustrated by the fact that I could have wrote a better more efficient query than EF. But EF and mapping tool are quite good in facilitating integrating between code and dB. Nevertheless in my case I have to customize and add some specific features in the EF part to manage update of object as well as other trigger in backend to ensure that my data are correct and can be exchanged. And this aspect is quite a nightmare from now. Perhaps for editing data is better to use classical DB direct Access and for viewing DB data to rely on EF for faster development. Anyway thank you for sharing your knowledge. Max
Thanks for the video Tim. We use Entity Framework a lot in our in house software, work in an internal software dev team. I'm still new to C#, .NET, come mostly from a Front end, JS development so this has helped me to understand that EF is not as simple as it appears with the hidden dangers. I still need to use it as that's what our projects are running but this has helped me to take it a bit slower and really think about what I'm doing. Thanks!
Thank you for this tutorial... its easier than I thought. Also thank you for showing us the "dark" side of EF. I will watch out when doing my queries. In the worst case I will just write a SQL query. Tbh I even prefer writing them instead of figuring out how EF creates them... but for quick and small stuff I think its fine.
Tim - Great video!! I've never really used EF primarily because it seemed more prudent to separate UI. models and the underlying storage. Your video confirmed that decision. I tend to lean on using SPs for nearly 100% of DB access using parameterized SPs and SQL. There is something comforting about being able to change an SP to impact performance and results without having to rebuild and re-deploy code. .. Thanks!!
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
I'm beginner in EFCore. I'm not beginner in SQL (not expert too))) ), but generated code by EF Core worried me too. I didn't think it so serious if EFCore generated them by default. Now I've understood that I have to learn EFCore deeper before use it. I only understand an Indian and Russian accent, but never understood an American accent (because they speak very fast). But I've understood each of words (some place with subtitles)))) ). It was amazing. Thank you a lot !!!! P.S. Sorry my english )
Thank you!! Ton of information in a single video. You highlighting multiple times about issues in production hit the chord with me. Hope you have/do some videos on memory leakage and exception handling.
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 ruclips.net/video/WGbTM198-eA/видео.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.
When I first encountered EF, I thought everything db related just got easier and I fell for the pitfalls discussed in this video. Something that was not discussed here is the overhead when using EF without AsNoTracking() when necessary. This is very educational. Thank you! Edit: I think using tools such as SSDT to manage your database and then use EF will help you develop better. Leaving everything to EF isn't looking attractive as of the moment.
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.
"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: ruclips.net/video/ijDcHGxyqE4/видео.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
Mr.Tim Corey, your courses are superb educational and great resources for learners of all expertise levels.
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!
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.
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.
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.
The fact that is 2.5 hrs tutorial and for FREE on youtube is ming boggling. Most people share knowledge in general. Thankyou so much Tim.
You are welcome.
While I didn't know about this channel, when I was trying to write migrations from other channels, no one went that deep, they didn't show the errors, and so I had a problem every time I found a problem myself. in the end, I lost my enthusiasm and instead of writing with migration, I switched to writing db first. when I discovered this channel, everything was great. Thanks
I am glad it was helpful.
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.
You are the best programming teacher I've ever met. Thank you so much for this content.
Thank you!
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.
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!
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.
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.
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!
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
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
What I love about this video is that you explain each topic with the right level of detail and in a succint and informative manner. Even someone who has primarly used Dapper loved the content and learned a lot.
Excellent!
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!
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!
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.
Hey Tim, your content not only helped me to understand code and program, but also helped me to see the problems in a completely simple way. Your way of teaching and talking out the solution is unique & simple. Thanks for that.😀
You are welcome.
I've been looking a lot of ef guides. I also have prior experience with it but never created a project from scratch myself, this guide is absolutely the best one I've found so far. Superb job and the flow you have is absolutelt great! Thanks a lot you saved me a lot of research time
Awesome! Glad I could help!
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!
Really well made and I love how you show the simple things that are so often missed.
Thanks!
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.
Tim Corey DOMINATES this market. The best quality videos. The most understandable videos. An absolute asset to YTs education sector.
I appreciate the kind words.
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
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.
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.
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!
Another Awesome real world explanation. Even the preamble with the ground rules on commenting and disclaimer that everyone can have a valid opinion - priceless! Fortunately, it looks like I’m coming to the party at just the right time for .NET and learning C#. I’m working on a transition with a friend from a PowerBuilder based product to work through what makes sense to move to C# and .NET Core (for the computational / Data crunching part of the solution). You’re content has rapidly gotten me oriented and confident about iterating through a solution. Thank you again!
-even more: You’re example right at the start is a Person with multiple addresses and emails - Real World requirement - and an explanation that communicates and causes the viewer to “think” but still simple enough to keep engagement. Wow!
Thanks for growing your skills with Tim thru this video.
Tim also knows about War and Peace book! It is astonishing by itself. He is not just a great programmer and teacher but he is a man of culture also.
Your's course not only explains how to build a program in Visual Studio but also is a great lesson of how to speak in english. Big thanks.
You are very welcome!
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!
Man! your videos always have fully explained satisfying answers to my questions. Keep up the good work
Thank you!
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).
Someone might've already posted so, but fun fact.
If you enable C#8's Nullable Context for the whole project, EFC will automatically adapt to that. Making all model fields by default [Required], and only making them nullable if the type is a nullable type (like: string?)
Thanks for the eye opening video, some of this stuff I had never thought about!
Thanks for sharing!
Really great advice! I had exactly this issue when I wanted to add some new fields to MS Identity table of users. I intended this fields (FirstName and LastName) to be optional but in the snapshot I saw that EF always made them obligatory. I tried to manually fix the migration before updating of the database but it failed and then I did exactly what you told and it totally helped.
Damn, its rare to find a creator who actually cares.
Thank you :)
You are welcome.
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.
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
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 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!
Thanks Tim! I wish I had this a couple years ago to share with my junior developers. I have had the same reservations as you for many years about ORMs in general. I have seen them totally derail an application once it hit production. My team used EF for the first time a couple years ago and I have been fairly happy with it, but this video pretty much sums up my feelings about it.
As a hiring manager, it has been a challenge to find newer developers that can work "without the net" of an ORM. I believe that knowing how to do both is critical to being an experienced developer.
Thank for sharing from that perspective. Appreciate!
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.
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
Thank you for this great tutorial. Cleared a lots of doubts I had.
Excellent!
Dear Tim! I've got a new job, thanks to Your videos! Keep up the good work!
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.
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
Simple, clear, easy to follow lesson on this important topic.
Thank you!
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
The first long video on youtube I watched from beginning to end. Worth every minute. Thank you for your hard work, smooth voice, and deep knowledge!
Glad it was helpful!
A video of this quality is rare - thank you so much for this.
I also learnt a lot from it. Well constructed and very clear.
Thanks for covering some of the pitfalls and nuances. :)
Thanks for watching and promoting Tim's videos.
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'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 ( ruclips.net/video/ijDcHGxyqE4/видео.html ) and then use Dapper for data access. It just depends on the situation, the team, etc.
I understand what you mean at @15:30 about feeling weird with the Web project knowing about EntityFramework. The way I solve this is by creating a extension method in the DataAccess project (we'll call it .AddDataAccess(this IServiceCollection services) ), and then inside of this method I wire-up the .AddDbContext(). Finally, in the web project, you can simply call services.AddDataAccess() inside of the ConfigureServices, and the web project doesn't need to know anything about EntityFramework. Works great. Thanks for all of your videos!
Thanks for the insights.
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 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.
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.
Another great video Tim. I have limited experience with EF but you are 100% correct about how it will kill you in production. Also the developers will be clueless on how to fix it when you ask them why their application is running such idiotic queries. You have to try to fix issues by creating indexes and harass them to purge unnecessary data from the tables. Using stored procedures definitely provides the maximum flexibility in fixing the issues. I am going to check out Dapper based on your recommendation. Many thanks for outstanding work.
I am glad it was so helpful.
Wow, this is really informative. You are correct that EF is really easy to use with many amazing query tools, code-first migration and etc. It is one of my favorite backend framework when I do project. However, I have got interned in one company that uses EF, we faced some issue with EF and some of them is what you mentioned in the video. It was years ago, we were using .net core 2.1 at that time. I am not working with them anymore, but I heard that they ended up rewrite partial of the project to optimize it.
This video taught me a lot, thank you very much!!
You are welcome.
Great information, Tim. Personal best practice is don’t use code first! Entity is great for help you quickly create class models and data access code but not for database creation. Thanks for all the great information as always!
Thanks for sharing!
Thanks for the video. You smashed it. You showed key points in terms of performance, diagnostic, debugging and others. However, I disagree in these points:
1 - if an inexperienced developer write a Data Access layer using dapper the consequences could be (IMO) 10x worse than using EF as an inexperienced developer. First, most of the time they (inexperienced devs) will handle the connection by themselves ( handling transactions, open-close dB , etc) they will create the UoW and Repo, they will do simple queries that maybe (I’m almost sure) will be not more performing than the EF ones, the data access layer will be not as tested and documented as EF, they will spent more time due to creation of all the data access layer, and more. Thus, if we compare what you can achieve as an inexperienced developer using both of the tools, I would argue that using EF can be less harmful and more efficient, than an inexperienced developer trying to create their own custom ORM or Data access Layer.
2 - In most companies there are developer team and database team. In my view devs would relegate the migration/maintenance/performance of the DB to the dB team and would work together when changes impact both sides.
3 - Premature optimisation is the root of all evil 👿. I would focus at the beginning in achieving then when performance issue are identified (hopefully, performance, loading, peek testing are done) then I would optimise the bit that cause a bottleneck (this should be done by someone with experience though)
4 - The learning curve is shorter using EF. Most .net developers will learn C# and then will learn some SQL. You could start delivering or producing work with only knowing C# and lambda expressions. However, I believe that we need more videos as the one you did, as they show a view on both worlds (C# - SQL Server) and of course learn sql as much as possible.
5 - I would consider to explain how you could change from SQL Server to another database vendor, using Dapper/EF and also would talk about how to change completely or handle different DB vendor. Cases: 1 Imagine I change the code to use only MySQL. 2 - Imagine I deploy you client with different database, ex Oracle, MySQL, Postgre DB. What would happen, what need to be done, how Dapper vs EF core or EF 6 would handle that, is that even possible or is the kind of things that you need to tell to your clients to f... up?
Other than that, I love the video and I learnt lots of it. Thanks 🙏🏼
1. I definitely think that you need to understand what you are doing before you write a data access layer (regardless of Dapper or EF). I do think that it is easier to make something without knowing anything if you are using EF. That's my issue.
2. I agree that this is ideal. If you do have two teams, why are you using code first EF? Dapper seems the more segmented and easier to keep performant route.
3. I would say that this phrase is the cause of a lot of the evils. There is a difference between premature optimization and writing good code. If you architect your application in a way that is inefficient, it will take a lot of rearchitecting to optimize it later. This introduces more bugs and causes more issues.
4. I would disagree that the learning curve of EF is shorter. It appears shorter but that is deceptive, as I demonstrated in this video. You think you understand what is going on until you hit production and it blows up. I had a lot of people tell me I should have just lazy-loaded my data and then everything would be good. That only works if you aren't doing a large display of your data (datagrid, etc.) If you do, then you actually made the problem worse. If you use EF, you NEED to understand SQL well to do it right. In a lot of cases, you might actually need to learn SQL better than if you were just using Dapper. If you just learn the C# side of things, you won't understand what is optimized and what is not.
5. My C# Application from Start to Finish course does replace the SQL connection (Dapper) with a custom text file system for data access. I also use pretty much the same Dapper code for SQL, MySQL, SQLite, and more in my various videos. I like the idea of showing how to swap out though.
IAmTimCorey thanks for answering. I really appreciate that you took time to read and reply my comment.
"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.
Just finished migrating from ef core to dapper best decision I've made, in dapper we are pulling paged data in milliseconds compared to at least a second on ef core,also your redis tutorial helped a lot with faster response 😃
Glad to hear it!
This is such a great roundup, taken from the point of view of using EF and diving into the beginning and continued maintenance and improvement of the application, and then going over how it doesn't fulfill its promises. I try very hard to avoid being that grumpy old dev who says "just learn SQL" but as you've pointed out, you need to end up knowing it anyways. And SQL is such a fine domain specific language for relational databases that it seems like all you're doing is learning this abstraction in between the concrete need to know and use SQL anyways.
Thanks Chris. Haven’t talked to you in what seems like forever. Hope you are doing well.
@@IAmTimCorey Hanging in there... can't wait to see you again at an event. I'm a fan of your work. I keep up with C# thanks to you and I really appreciated this thoughtful dive into EF with an objective yet skeptical point of view. Every time I think there is something more to teach I realize it's covered at IAmTimCorey... no joke...
Love when you said " I know I'm getting a Lot into SQL here"... Well thats the thing, if You want to use SQL without ADO you still need to know how EF uses SQL underneath.
Great content, marvelous execution, superb knowledge.
Thank you!
Hey Tim. I’m only 28 minutes in and I’ve been using EF for years. I’ve been using the tooling, and not really understanding why, like ‘okay, this tutorial says I have to put EF in with my web stuff’ and it’s never felt right, but i’ve just gone ahead and done it, you’re the ONLY person who has validated my inner concern, I’ve never expressed it because it was just a wrong feeling. Also, where you say you need to know a lot of the advanced EF stuff, I 100% agree. EF is so quick and easy you just start using it, it’s when you really start to use it, you can find yourself going down a rabbit hole and not understanding. Sorry, one last point. I would, from experience like to mention that you really should understand SQL even just a little when using Linq and EF. I knew nothing when I started and EF and Linq made me lazy about learning SQL. I’m still no expert on SQL but getting better. Thanks for your tutorials, you really give real world examples and explanations which, in many occasions it’s a light bulb moment. Thank you
I am glad it was helpful.
Thanks for making this video, was blindly using EFF Core until I watched this full video, man, what an eye-opener
Glad it was helpful!
It's really a great video for a beginner who wants to refactor the existing application from any other platform to C# and EFCore. Thank you, Corey!
Thanks for trusting Tim to help you build your skills.
As someone who is learning c# for work and who is generally framework averse because of just how much they typically do for you, thanks for the excruciating detail. very very helpful
You are most welcome. Thanks for watching.
The intro is great. You set the rules on ranting etc. I like that you're somewhat critical of EF. I actually like using EF but I want a balanced opinion. I'm really looking forward to this content.
Thanks! I am glad you appreciated it. I'm all for healthy debate. We just seem to have so little of it recently. I want to promote the right way to disagree and still respect each other.
Your content and delivery is simply great.. and easy to understand. Thank you so much for the wonderful tutorials.
I am SO excited to see you finally covering this topic!
Great!
Wow, this is an amazing video! We were taught to use EntityFramework Core at my university, but they did not mention ANY of these huge drawbacks and how to overcome them.
I'm not surprised. People often tend to gloss over them when evaluating EF.
Hi Tim, thanks for these videos, they are really good.
However a minor correction to some of your data type comments -- ASCII has only 127 chars, later extended to 255 chars, whereas UNICODE has 65,535 chars, later extended to ~138k chars.
Also I would argue that decorating entity primitive properties with DataAnnotations is not 'optimization' but a necessary part of your model specification, just as much as adding the properties to the entity in the first place. Of course EF code-first cannot generate a sensible data schema until it is provided with this information. MS documentation makes this clear too.
I agree with you on annotating with SQL-specific DB types like "varchar" though. That is far from ideal, and could even be breaking with future SQL Server updates etc. It is possible that there is an alternative sensible annotation that lets you specify a character set or text encoding type instead, which would be a much better way of achieving the same result.
Yeah, slip of the tongue there. As for entity decoration being necessary, I agree but that isn't something that is required or necessarily taught right away. That's what I'm indicating is dangerous. Out of the box, if you use EF without a much deeper knowledge, you cause problems. At the end of the day, some of the benefits that EF is sold on are disingenuous, since we have to do more work then we are told.
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.
Hi Tim, thanks for the video! I don't like the code first approach just the same reason you demoed in the video. So in our projects, we use db first. And we do the revision control though the scripts, similar like flyway. I am glad that we avoided most of the pitfalls in the video. I think the benefit of EFCore is that after you knowing how EFCore works (although you might spend some time to learn), it's quite productive, and since it's ORM, it can keep the code base quite clean (again, we don't use code first:) this is important). Although dapper also has things like simpleCRUD, but you need do more stuff when handling for example, many to many scenario. In conclusion, learn EFCore well then it will be quite benefit. Thanks!
It all depends on where you want to do the work. I'd rather write a SQL script rather than verifying the design of each query and the performance implications of it.
It is 100% true that scaling a SaaS app used by a lot of users takes more or same knowledge of SQL when using an ORM (be it Hibernate in Java, ActiveRecord in Rails, dj-orm in Django or Ef Core in C#) than you would if you wrote SQL directly. Every big app that I worked on, ultimately rewrote performance critical pieces using direct SQL queries at some point.
Plus, using ORM it's very easy to write bad code. For example, no one would purposely put an SQL query inside a loop when writing raw. However, your ORM code making magic queries to fetch associations lazily, is harder to see when written inside a loop causing N+1. I have spent an entire year, fighting bad cases of N+1 and still wasn't able to solve all of them because of how fancy Object Oriented design was made. Seriously, respect the DB operations when making a DB bound app.
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.
Finally. I have been seeing the Entity framework for over 6 years and never liked it. But all the tutorials about .net pushing me to work with the Entity framework. I know some of these issues about entity framework but your clear out more thing no one ever does. That's really are awesome.
Glad I could help!
went through the whole video and do along with it. I'm deciding whether use Dapper or EF Core in this moment, the deep analysis made a long video never felt long, all information is really valuable. thank you!
Glad it was helpful!
Hey Tim, i would like to thank you personally because you have done great video work...I really understand everything that you explain in video. I have just started a few months ago a coding bootcamp and your videos are extremely helpful. Well done. I wish you everything best!!!!
You are welcome.
Hi Tim,
First of all thank you for this video and for all videos posted on your channel. All very reliable content. I watched your video because I asked a company to rewrite for Windows platform an old application I inherited. They came back with a windows forms, C# and EF solution. I am now in charge of the maintenance of the application and as DB designer and with very good knowledge of SQL I am always skeptical with all these frameworks. In past life I was also maintaining a Java/hibernate web site. I must admit that EF seems to generate a correct SQL query than hibernate 5 years ago ( perhaps it has improve since then). To be noted that the database is well normalized, not fully obviously. So as a DB manager I am sometime frustrated by the fact that I could have wrote a better more efficient query than EF. But EF and mapping tool are quite good in facilitating integrating between code and dB. Nevertheless in my case I have to customize and add some specific features in the EF part to manage update of object as well as other trigger in backend to ensure that my data are correct and can be exchanged. And this aspect is quite a nightmare from now. Perhaps for editing data is better to use classical DB direct Access and for viewing DB data to rely on EF for faster development. Anyway thank you for sharing your knowledge. Max
Thanks for sharing.
Thanks for the video Tim. We use Entity Framework a lot in our in house software, work in an internal software dev team. I'm still new to C#, .NET, come mostly from a Front end, JS development so this has helped me to understand that EF is not as simple as it appears with the hidden dangers. I still need to use it as that's what our projects are running but this has helped me to take it a bit slower and really think about what I'm doing. Thanks!
I am glad it was helpful.
I'm French , and i've understnd every things you explain , THANK YOU VERY MUCH , I will start to lurn DAPPER , with yours courses
I am glad it was so clear and helpful.
Thank you for this tutorial... its easier than I thought. Also thank you for showing us the "dark" side of EF.
I will watch out when doing my queries. In the worst case I will just write a SQL query. Tbh I even prefer writing them instead of figuring out how EF creates them...
but for quick and small stuff I think its fine.
You are welcome.
That was amazing, Tim. Thank you very much for all the work you have to put this explanation up.
You are welcome.
Awesome tutorial. I don’t even want to call it a tutorial, more like training or a small boot camp on EF Core . Thanks Tim!
You are welcome!
Tim - Great video!! I've never really used EF primarily because it seemed more prudent to separate UI. models and the underlying storage. Your video confirmed that decision. I tend to lean on using SPs for nearly 100% of DB access using parameterized SPs and SQL. There is something comforting about being able to change an SP to impact performance and results without having to rebuild and re-deploy code. .. Thanks!!
Glad it was helpful!
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
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.
I'm beginner in EFCore. I'm not beginner in SQL (not expert too))) ), but generated code by EF Core worried me too. I didn't think it so serious if EFCore generated them by default. Now I've understood that I have to learn EFCore deeper before use it. I only understand an Indian and Russian accent, but never understood an American accent (because they speak very fast). But I've understood each of words (some place with subtitles)))) ). It was amazing. Thank you a lot !!!!
P.S. Sorry my english )
Thanks for sharing!
The best tutorial about EF I have ever seen😍🔥🔥🔥🔥🔥 thanks Tim
Wow, thanks!
Thank you!! Ton of information in a single video. You highlighting multiple times about issues in production hit the chord with me. Hope you have/do some videos on memory leakage and exception handling.
Glad it was 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 ruclips.net/video/WGbTM198-eA/видео.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.
When I first encountered EF, I thought everything db related just got easier and I fell for the pitfalls discussed in this video. Something that was not discussed here is the overhead when using EF without AsNoTracking() when necessary. This is very educational. Thank you!
Edit: I think using tools such as SSDT to manage your database and then use EF will help you develop better. Leaving everything to EF isn't looking attractive as of the moment.
I'm glad it was helpful.