Man, there are hundreds of videos on “how to EF”, and that’s fine. But your walkthrough here that included not only that, but also the pitfalls, what could cause problems, and WHY those can be problems was extremely helpful. The section explaining the string fields like NVARCHAR(MAX) was very informative and helpful.
@IAmTimCorey
Жыл бұрын
I am glad it was so helpful.
@jamesbest3347
4 жыл бұрын
"If the way someone develops a C# application makes you angry, I suggest you reevaluate your priorities in life." LOL legend
@IAmTimCorey
4 жыл бұрын
lol thanks.
@jamesbest3347
4 жыл бұрын
@@IAmTimCorey Tim, I also wanted to say I agree with you 100% on your disposition towards Dapper. For smaller applications where you might have a single login that's connected to very minimal amount of user data I believe EntityFramework is a great tool because you don't need to know much about the DB as it's all handled with a model first approach. It's when your small application turns into a larger thing that you realize you wish you were managing this stuff yourself because the migrations start becoming a real hassle and performance can start to decrease. That said, does Dapper have a similar tooling to EF in that it will generate a migration or SQL script to create your DB from the model? Writing queries isn't really an issue for me, but I really do like the model first approach of EF. Thank you!
@IAmTimCorey
4 жыл бұрын
I haven't found one I liked yet and I'm considering writing one.
@IAmTimCorey
4 жыл бұрын
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: kzitem.info/news/bejne/yqB6yXx9sauieGk
@JasonDias7
4 жыл бұрын
@@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
@metax73
3 жыл бұрын
If all of your other videos are this detailed, I'm going to watch your entire library. I was expecting to to see a couple instances of how to do something in Entity, but this video was so much more valuable then that.
@IAmTimCorey
3 жыл бұрын
I try to be thorough in everything I teach. It is all about being real-world ready.
@EricHarmon67
4 жыл бұрын
I watched this video with great interest, and I have some comments to make. I have used Entity Framework fairly extensively since EF 4, up until EF Core 2.x. I didn't get a chance to use EF Core 3.x in production, as I retired three months ago. That should give you an indication of my frame of reference as it relates to EF. Anything I see here is, of course, the way *I* worked, and I'm not claiming my way was the best - only that it well worked for me, and in some cases reduces or eliminates some of the areas that you pointed to as causing you some concern. First, I would never allow any data access tool, EF or otherwise, to create the database for me. Though I wasn't a DBA per se, I created multiple databases for use with my applications, and I always created those databases manually in SSMS. Not only did that allow me to define the tables and columns in exactly the way I wanted (for example, I didn't need to know or care whether EF (or nHibernate, etc.) pluralized table names), but I could also create secondary indexes in the "normal" way in SSMS, without needing to learn anything about how EF data annotations (or fluent API) worked for defining indexes and so on. I just think it's better to have complete control over the database structure. The only thing I ever used data annotations for was for required or max length, which allowed the UI to perform validation of data via Validator.ValidateObject(), et al. You showed the long sp_executesql query generated by EF. I actually never encountered that, as that's something new in EF Core 3.x. In EF "Classic" and EF Core 2.x, one insert statement was sent to the database per row insert (and all the inserts were performed in a transaction). It's interesting to note that the EF team got crucified for that approach, as it caused numerous INSERT statements to be sent to SQL Server when bulk inserting. I myself encountered more than one occasion where I saw an order of magnitude or better performance increase when I used EF addons such as EFCore.BulkExtensions and the like, in the few cases where I needed to insert many rows into the database at once. Now that the EF team wrapped the multiple inserts into a single statement, they're again facing criticism. I'm not any kind of security expert, so perhaps there's a better way they could have reached the same end goal, but definitely sending a single SQL statement per inserted row wasn't being happily accepted. I personally never used migrations, as I found them to be too limiting (at least, when I looked at them; it's possible they gained functionality later on). I found that in many cases when I made a database schema change, I needed to do some serious work on the data. For example, I might factor out three columns from one table and two columns from another table and put them into a new table, referenced by both of the original tables. That kind of work didn't lend itself to migrations, so I wrote a little "framework" for database updates, and then whenever I had occasion to update the database, I filled in the guts of the framework with the handcrafted SQL statements that I needed. So I didn't use EF at all for database migrations. I wrote desktop applications, and I was able to completely encapsulate EF into a .NET Standard 2.0 class library, with no reference whatsoever from the UI project(s). This might be different for me because I didn't write web apps (though I'm assuming this would work equally well for a web app), but I got the (encrypted) server name, database name, user id, and password from a local config file, and then passed those to a static method in the data access library, which cached the information. I wrote a UnitOfWork class that encapsulated the DBContext, and the application made calls to UnitOfWork. The UnitOfWork class instantiated the DBContext, using the cached connection information. The main application never knew it was using Entity Framework at all. Finally, I don't think the query where you loaded all people, addresses, and email addresses was a fair one. You wouldn't load them like in reality that unless you planned to do a bunch of updates to all the data and then resave it. Instead, you'd use DTOs and you'd have a projection query, the same as I imagine you'd do when using a different ORM, or when issuing direct SQL statements. I have, though, on occasion done the same thing in EF Core (2.x) that you said you do in Dapper, which is to issue two or more SQL statements independently, and then merge the resulting data using C#. I understand what you're saying about needing to learn EF before using it, but I would argue that that can be said about literally any technology. I wouldn't want to sit down and try to write an application using Dapper (I've never used Dapper before) without studying it fairly extensively. I wouldn't allow Dapper to automatically create the database, just as I wouldn't allow EF, nHibernate, or anything else to create it. So I think that you're being a little bit hard on EF, as it's an incredible data access technology. In my opinion, the types of "gotchas" that you point out relate to any technology, including direct SQL / ADO.NET. I can easily write a horribly performing, though straightforward, query, in direct SQL. For example, I've seen tons of examples that show "SELECT * FROM Customers", which you wouldn't (hopefully) ever do in real life.
@IAmTimCorey
4 жыл бұрын
I do like that EF passes a big chunk of inserts to the database to process. That definitely is more efficient than individual inserts. The issue is that in order to do that, you have to enable the use of sp_executesql, which can be dangerous. EF does not use it in a dangerous way but the permissions to run that stored procedure have to be on the calling machine, so that opens up the option for someone to call it directly (a danger). As for not using EF until you learn it, I agree that we should learn everything before we use it. My point was that you should be at a much higher level of knowledge before you use it in a real application. The way it is pushed is to use EF when you don't know SQL or if you want easy data access that "just works". That's what I don't like to see. I've cleaned up way to many of those messes.
@zacboyles1396
4 жыл бұрын
@@IAmTimCorey thanks for your videos. I like to have tutorials and conferences playing off to the side while I work so I can catch good bits. I've been using EF Core 2 and 3 with Azure web and Azure functions deployments but I've never seen a message to reference the UI or any other project. My data is always in an isolated project and the solution builds correctly. Maybe it's something with .Net standard, I've not spent any real time with it. Also, I definitely agree with what you're saying about developers writing their models without annotations however, those same devs would be the ones to use nvarchar(max) using SSMS lol. You're a bit too harsh on EF there. I might even argue that far more EF tutorials use annotations than typical .net tutorials with SQL. Actually, the c# side of those tutorials typically include the constraint information so to demo validation features whereas the database portion is quickly skimmed over. Anyway thanks for all the hard work, hope I didn't come off as negative with the data types, I just wanted to defend EF a bit. I enjoy how thorough your videos are.
@bonkers_dave
4 жыл бұрын
Eric, this is three months old, so I don't know if anyone is paying attention. I too am a grizzled veteran with years of experience with EF, but I have to disagree with your level of absolutism on things like "I would never allow the data access tool to make the database for me". In the early-ish stages of prototyping and proof-of-concept, especially in the brave new world of micro-services, the code-first cycle with migrations is a huge productivity tool. For a team, you need to establish a process. It used to be that the "prototyping" phase would last a couple of months and then the system life cycle would be five years. But in the era of micro-services, we're prototyping something or other all the time, and there isn't One-Big-Database-In-The-Middle.
@user-hz1yc6cw6k
4 жыл бұрын
There is one more point against generating database schema from EF annotations: security. To generate database, EF must be connected with credentials allowing to use DML, wich is too high level of permissions in the most of the cases. And, by the way, in ideal world, database design is the job of database developer and security is the job of DBA. But everything today is being outsourced to replaceable masters of nothing and we have to live in the world where students outsourced as "full-stack" senior develovers do everything at once.
@henrybotha
4 жыл бұрын
@@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.
@tchpowdog
4 жыл бұрын
I agree with everything your saying here in regards to having to be experienced in order to use EF efficiently. However, everything you laid out is from a "code-first" perspective. I use EF in all my projects, but I don't use their migration and schema tooling. I use good-ole fashioned DB-first approach. I use SSMS as much as I use Visual Studio. Also, I only use EF for entity level CRUD operations and very basic queries. If I have ANY more-than-basic queries or data logic, I use SPs, Views, Functions, etc. - then I call those functions through EF. I wouldn't recommend using EF for a code-first approach, either. However, I wouldn't recommend code-first AT ALL. Personally, I despise the code-first approach - but I also appreciate the fact that it works for other people.
@IAmTimCorey
4 жыл бұрын
Yeah, I think the big takeaway is to be careful and know what you are doing really well. Code First, which is the method that is most often pushed, can be done well if you are careful but if you aren't, you can create a mess.
@LiganPL2
4 жыл бұрын
I have the same opinion as you. In my company it looks the same as you explained. We never used code-first model.
@znk0r
4 жыл бұрын
Curious to know a bit more about what makes you despise code first. We had a team discussion before starting a second code first project and we mostly agreed we liked the fact that devs could focus on what made sense in code and have the ability to refactor without having to create the schema updates themselves. Yes you have to handle the data updates and merging stuff between branches but we still felt it was worth it. It wasnt 100% unanimous so outside opinions are interesting.
@tchpowdog
4 жыл бұрын
@@znk0r I just like the database first mentality. I am a systems architect and I build web applications, pretty much only web. SQL and Oracle are incredibly powerful and I feel they are under-used with a code-first approach. I believe one's first intuition should be to place logic in the database via SPs, Functions, etc (of course this isn't always the right thing to do). Being database first also aligns with my system architecture philosophy, which is: Lightweight Web API that scales horizontally Heavy database that scales vertically Fast front-end framework (Angular or React) I understand there are trade-offs either way and a lot of it depends on the application. I guess the thought of a programmer creating a database without much knowledge of databases scares me, so I'd just assume not go there lol For example, I hired a brilliant programmer about two years ago and he has done a great job, but he never learned SQL or Oracle in school. That's scary to me. When you reach scale, you can put yourself way behind by running into severe performance issues if you don't know how databases work. But like I said, I do appreciate the fact that it works well for others.
@timetorelax45
4 жыл бұрын
@@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.
@TehDarkWolf
4 жыл бұрын
I feel like it's still important to learn it for people who are planning to get into professional industry. EF is widely used in many companies ranging from small to large, I honestly I have heard of dapper until I came across your channel. The best way to learn is to use the frameworks, if you consistently avoid well-known frameworks you won't really grow as a developer and limit yourself in the professional world.
@IAmTimCorey
4 жыл бұрын
True. You will face it so you should learn to do it right. I would recommend learning it later on in your C# development training. In my Foundation in C# course series, I teach it in module 8 (out of 10): www.iamtimcorey.com/p/complete-foundation-in-c-course-series
@objectaware5296
4 жыл бұрын
I agree. Most MS Stack shops use EF but you should have a good knowledge of SQL and Database design, in most orgs, you're the DBA. If the shop does not have formal code review, find the most knowledgable people in each discipline and ask them to review your code. You'll learn something most times.
@joeyf9826
2 жыл бұрын
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.
@gasparottogui
4 жыл бұрын
Hey Tim, thanks for another great video! I've been learning a lot in your tutorials and it's impressive to see how deeply you understand the language and how clearly you explain it. Thanks for sharing!
@IAmTimCorey
4 жыл бұрын
You are most welcome. Thanks for the encouragement.
@vkumbaji2010
3 жыл бұрын
Mr.Tim Corey, your courses are superb educational and great resources for learners of all expertise levels.
@alanskaev
3 жыл бұрын
This video is so detailed and thorough it shouldn't even be free
@IAmTimCorey
3 жыл бұрын
Thanks!
@UnknownMoses
3 жыл бұрын
No it should not be free.
@bengardiner5880
3 жыл бұрын
@@UnknownMoses i mean im quite happy is free
@imanqoly
2 жыл бұрын
Totally agree with you
@lolop2576
4 жыл бұрын
I consider myself a pretty experienced EF developer, but had only just learnt about the drawback of using Includes from this video. I had assumed it did something along the lines of QueryMultiple in Dapper. Just shows it's always worth looking at videos on topics you consider yourself well versed in. One thing I was waiting for you to bring up was projections. Using Select statements is an extremely important part of making sure that EF runs smoothly for me. It solves the issue of Include, and removes the change tracking which is another big cause of slowdowns. Using projections you can get near identical performance to Dapper, while also keeping all the benefits of EF core. One of the most important things for me is the compile time safety of my queries. Admittedly I haven't watched your videos on how you use Dapper yet so I'm not sure if you've addressed this. I also think using the right tool for the job is an important aspect. If a query is complex and needs to be hand crafted for performance, writing the SQL manually and using dapper is the better option. If you just want to pull a few fields from a table or two and put it into a VM/DTO, I think EF with projections is usually better. I'm not against using both in the same project and using EF for 90% of my needs, and Dapper for the last 10% of more tricky/important aspects of the application. Lastly, in case you didn't know, you should be able to change the 'Logging.LogLevel.Microsoft' in the appsetting.json to be 'Information' and all the queries run by EF core will be logged to the ASP.net console. I find it much easier to look at the queries as they go through there than trying to filter through the junk in SQL Management Studio. Just my 2 cents, great informational video overall, especially for newer developers!
@IAmTimCorey
4 жыл бұрын
Yeah, I just touched on some of the topics. There is a lot to cover. I'm glad you enjoyed the video.
@dzllz
Жыл бұрын
Great points. Select solves the issues of include
@justtohide
Жыл бұрын
While I didn't know about this channel, when I was trying to write migrations from other channels, no one went that deep, they didn't show the errors, and so I had a problem every time I found a problem myself. in the end, I lost my enthusiasm and instead of writing with migration, I switched to writing db first. when I discovered this channel, everything was great. Thanks
@IAmTimCorey
Жыл бұрын
I am glad it was helpful.
@InsolentDrummer
2 жыл бұрын
The reason I find Tim's channel so useful is because he always explains why we do certain things one way and not the other and not just because he said so!
@IAmTimCorey
2 жыл бұрын
Thanks!
@fabiajero
4 жыл бұрын
You are the best programming teacher I've ever met. Thank you so much for this content.
@IAmTimCorey
4 жыл бұрын
Thank you!
@qutiephoebe2154
4 жыл бұрын
You dont find these best practices and tips from other videos... They just teach you how to write code... That explanation and difference on approved age in the where clause is bravo!👏👏👍👍
@IAmTimCorey
4 жыл бұрын
Thank you. That's what I attempt to do with all of my videos.
@GuySymonds1
4 жыл бұрын
Where was this tutorial when I was trying to learn EF so many years ago. Really well made and I love how you show the simple things that are so often missed like where the PackageManager Console is in Visual Studio. I'll be watching a lot more of these videos, keep up the great work.
@IAmTimCorey
4 жыл бұрын
Awesome!
@rakip3188
2 жыл бұрын
Small correction: Ascii has 256 characters Unicode has 143,859 characters Thank you Tim for your hardwork in putting these videos together. Greatly appreciated 🙏
@akuskus
2 жыл бұрын
And even smaller correction: ASCII is written in all capital letters.
@ahmedifhaam7266
Жыл бұрын
@@akuskus that's not really a correction of data, just convention, OP actually gave a correction by providing new facts.
@akuskus
Жыл бұрын
@@ahmedifhaam7266 true
@anubhavdebnath2747
Жыл бұрын
small correction ASCII should be written in all capital
@mehedihasanopu5666
Жыл бұрын
Thank you Tim Corey. It's a great chance for us to learn from your courses. For checking if there is any record in table, Any() functions should be used for better performance. Count() has to read the whole collection of the table but Any() immediately returns after reading a single record.
@IAmTimCorey
Жыл бұрын
Thanks for sharing.
@greenwalmart
Жыл бұрын
Tim, you did an great job covering this topic. I try to tell people that programming is the last thing that you do. And your videos demonstrate this. You have to know exactly what you're doing or pay the price on the backend. Awesome video!
@IAmTimCorey
Жыл бұрын
Thank you!
@CodeYourselfToDeath
2 жыл бұрын
Dude your tutorials and calm and collected explanations are top notch. For real if you like this youtube thing, don't give up on it. You make excellent videos!
@IAmTimCorey
2 жыл бұрын
Thank you!
@vivekkaushik9508
Жыл бұрын
The fact that is 2.5 hrs tutorial and for FREE on youtube is ming boggling. Most people share knowledge in general. Thankyou so much Tim.
@IAmTimCorey
Жыл бұрын
You are welcome.
@E-Dh
4 жыл бұрын
i am currently using this video as a go to guide whenever a friend of mine mentions using EFCore. Thank you Tim, you really are awesome !
@IAmTimCorey
4 жыл бұрын
You are welcome.
@AndrehHimself
3 жыл бұрын
Just passing by to say: THANK YOU TIM! Your videos are awesome and are really helping to move towards a dev career, what you do for the community has granted you a place in heaven. Keep up with such amazing work, cheers!
@IAmTimCorey
3 жыл бұрын
Glad you like them!
@torrvic1156
Жыл бұрын
Your lessons are pure gold Mr. Corey! Some things you said I learned the hard way via trial and error myself but other things you advised can’t be underestimated. Such a good advices you are giving to us! You even know about War and Peace book and it tells us as to how knowledgeable and intelligent you are. I am amazed by your charming personality Tim! Thank you so much!
@empathetic24671
2 жыл бұрын
Hey Tim, your content not only helped me to understand code and program, but also helped me to see the problems in a completely simple way. Your way of teaching and talking out the solution is unique & simple. Thanks for that.😀
@IAmTimCorey
2 жыл бұрын
You are welcome.
@salmanahmedazmi3084
2 жыл бұрын
Really well made and I love how you show the simple things that are so often missed.
@IAmTimCorey
2 жыл бұрын
Thanks!
@gedwistle1974
4 жыл бұрын
Not sure if this has been addressed in comments already, but for your first issue about having to reference EntityFrameworkCore from the web app in order to call services.AddDbContext, you can simply reverse the dependency. I use a static method on my Context partial class that takes the IServiceCollection as a parameter. This allowed me to remove the reference to EntityFramework from my web app project all together.
@IAmTimCorey
4 жыл бұрын
Thanks for sharing.
@soucianceeqdamrashti8175
2 жыл бұрын
What I love about this video is that you explain each topic with the right level of detail and in a succint and informative manner. Even someone who has primarly used Dapper loved the content and learned a lot.
@IAmTimCorey
2 жыл бұрын
Excellent!
@iandalrymple7255
Жыл бұрын
"If someone's opinion about how to write C# makes you angry then you need to re-evaluate your priorities." This intro made me chuckle. So true.
@IAmTimCorey
Жыл бұрын
lol, glad you enjoyed it.
@RyomaGG
3 жыл бұрын
16:58 You can put in an override for OnConfiguring in the PeopleContext class protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { base.OnConfiguring(optionsBuilder); optionsBuilder.UseSqlServer(Configuration["ConntectionStrings:YourConnection"]); } Therefore your front end no longer knows about entity in this circumstance.
@milanpospisil8024
3 жыл бұрын
Yes, there are many techniques that can do that.
@tomthelestaff-iamtimcorey7597
3 жыл бұрын
Thanks for sharing the tip!
@get_ready
4 жыл бұрын
Amazing video. I'm pretty new to EFC and total newbie with SQL. I learned a lot from this video, and it made me realize that I should in fact invest more time to learn what I'm working with. Thank you!
@IAmTimCorey
4 жыл бұрын
Excellent!
@celebrim1
4 жыл бұрын
So my experience with EF is that its strengths are exactly what you would expect it's strengths to be if you understand how it works and you rolled your own. What EF does well, and what might tempt me to bring it in as a solution to a specific problem, is build a search engine. Because Entity Framework at it's core is a dynamic SQL builder. If you don't know really what combination of filters are going to be applied to the data set then entity framework provides a really intuitive and straight forward way to build dynamic SQL, which is something you need if you are going to build a performant data search when you don't know exactly what where clause you are going to need. And that's great, but the tradeoff is bad. For all other problems, I find that Entity Framework is a toy solution. And by that I mean that it makes tasks which are simple and straight forward, like atomic CRUD operations easy. But, the characteristic of a toy solution is that it makes non-trivial tasks harder and more complex, both to create and to debug. Once you start getting to sufficiently complex real world operations, which are non-atomic, which ideally will involve reading multiple datasets, and so forth, then entity framework doesn't make things easier than rolling you own straight forward DALC's with old fashioned ideas like connections and readers. It in fact makes it harder. There are more unintended side effects and more work involved in avoiding unintended side effects. If you start working with 40 joins, some of which are filtered, then the fact that left join is not naturally supported by the syntax and the fact that your LINQ itself starts getting really complicated, and fact that you are forced to hacky patterns like unnamed objects or projections, which result in massive potentially hundreds of lines long single statements that are inherently brittle and defeat any advantage of EF in the first place. I find you still have to end up creating cache objects because EF's caching isn't intelligent enough to manage itself and managing yourself is harder than just rolling your own. And don't get me started on the fact that it can't do multiple datasets but instead goes cartesian nuts by trying to push everything into a single result set.
@IAmTimCorey
4 жыл бұрын
Yep, pretty much.
@timrobertson8242
3 жыл бұрын
Another Awesome real world explanation. Even the preamble with the ground rules on commenting and disclaimer that everyone can have a valid opinion - priceless! Fortunately, it looks like I’m coming to the party at just the right time for .NET and learning C#. I’m working on a transition with a friend from a PowerBuilder based product to work through what makes sense to move to C# and .NET Core (for the computational / Data crunching part of the solution). You’re content has rapidly gotten me oriented and confident about iterating through a solution. Thank you again! -even more: You’re example right at the start is a Person with multiple addresses and emails - Real World requirement - and an explanation that communicates and causes the viewer to “think” but still simple enough to keep engagement. Wow!
@tomthelestaff-iamtimcorey7597
3 жыл бұрын
Thanks for growing your skills with Tim thru this video.
@torrvic1156
Жыл бұрын
Tim also knows about War and Peace book! It is astonishing by itself. He is not just a great programmer and teacher but he is a man of culture also.
@idis5702
4 жыл бұрын
you can use Iqueryable method for where clause, like predicatebuilder that is functional and also it is easy to use
@IAmTimCorey
4 жыл бұрын
Can you show me an example of what you mean? I'm not quite understanding what you are saying.
@Doomchild_
4 жыл бұрын
@@IAmTimCorey I would change the return type of the ApprovedAge method from bool to Expression and return x => x.Age >= 18 && x.Age
@sufyaniqbal8939
4 жыл бұрын
This One lecture is better then my half semester in uni. Thank you so much for your kind effort ❤️ Love from #Pakistan
@IAmTimCorey
4 жыл бұрын
You are most welcome. Thanks for watching.
@sufyaniqbal8939
4 жыл бұрын
@@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.
@asheeon
4 жыл бұрын
Someone might've already posted so, but fun fact. If you enable C#8's Nullable Context for the whole project, EFC will automatically adapt to that. Making all model fields by default [Required], and only making them nullable if the type is a nullable type (like: string?) Thanks for the eye opening video, some of this stuff I had never thought about!
@IAmTimCorey
4 жыл бұрын
Thanks for sharing!
@torrvic1156
Жыл бұрын
Really great advice! I had exactly this issue when I wanted to add some new fields to MS Identity table of users. I intended this fields (FirstName and LastName) to be optional but in the snapshot I saw that EF always made them obligatory. I tried to manually fix the migration before updating of the database but it failed and then I did exactly what you told and it totally helped.
@novemberdev8292
4 жыл бұрын
I use EF to build the Tables and do Insert, Update and Delete, but then I use Dapper for advanced SQL queries, it has been a blast so far!
@IAmTimCorey
4 жыл бұрын
Great!
@nikoskondylis5618
4 жыл бұрын
Thank you for all your excellent tutorials! One side note I would like to make if I may. The EF design tools can be installed in the EFDataAccessLayer class project. After you install the tools in the class project, make this project as startup project from Visual Studio solution, run your migrations from PM> and switch startup project to UI project when you want to run the application.
@IAmTimCorey
4 жыл бұрын
Yeah, it is just a pain to do so.
@HekmatKhyber
4 жыл бұрын
Hummmm, in my whole development life this is the first time to see this type amazing explanation. Great job.
@IAmTimCorey
4 жыл бұрын
Thank you!
@HekmatKhyber
4 жыл бұрын
@@IAmTimCorey now you are our instructor, I have learned much techniques from your best tutorials.
@Thespartanassassin1
2 жыл бұрын
I've been looking a lot of ef guides. I also have prior experience with it but never created a project from scratch myself, this guide is absolutely the best one I've found so far. Superb job and the flow you have is absolutelt great! Thanks a lot you saved me a lot of research time
@IAmTimCorey
2 жыл бұрын
Awesome! Glad I could help!
@abb1806
2 жыл бұрын
For today a little bit outdated, from version 5 we can use AsSplitQuery, and most of the problems disappears almost instantly, version 6 even much better. Regarding knowing SQL, I agree that is important to know SQL, but is very different to know SQL and to know where to identify problems, than to work on daily basis with SQL. I'm using EF core for more than 3 years and I can keep my apps running on production without any significant loss on performance, and at the other hand the ORM and migrations keep my environment safe , so every small change on schema/structure I MUST change my code everywhere is used, something that was part of my constants nightmares while I worked with SQL SP/Views years ago. I need to admit, that sometimes I need to rely on views with CTE or similar SQL specifics performance helps (indexed views). But in 99% cases is much easier to write and separate steps (and reuse) writing queries inside EF than directly SQL
@tmfink10
3 жыл бұрын
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?
@jasonargo9085
2 жыл бұрын
Probably not considering I just created a new VS2019 project with EF Core and all of the configurations are still present as they were when this video was uploaded, including all the nvarchar(max) nonsense
@markippo
2 жыл бұрын
@@jasonargo9085 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.
@jasonargo9085
2 жыл бұрын
@@markippo Yes, I wrote that comment at a time when I knew a lot less about the subject than I do now. Most of that comment was me probably trying to figure out what tools I wanted to learn
@davestorm6718
2 жыл бұрын
@@markippo - I've found that EF is too "black box" for my tastes. But then again, I come from a database first (and have for 20 years) approach to applications, and it's never been an issue for me. Also, when I see code-first implementations, it appears that you end up having to muck about the database anyway (not to mention security issues, the ridiculous number of superfluous calls made to the database by EF, etc). This and, honestly, how often do you change your database to a completely new system? In 2 decades, I've only seen it done once, but then again, the ENTIRE stack was changed from DotNet/SQLServer to LAMP (and it was, to say the least, the dumbest move I've ever seen a company do, all because some idiot didn't want to pay a few grand for SQL Server - they blew a million bucks in labor to save a few grand).
@frankolee4892
2 жыл бұрын
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!
@ioannisstefanou9140
4 жыл бұрын
Hey Tim, great tutorial. I enjoyed the details on where entity framework falls short -- they actually gave a great insight to how this system operates behind the scenes. I would like to propose a suggestion for a tutorial as to how would you implement a repository/unit of work patter on top of entity framework. Thank you for all your hard work. Subscribed
@IAmTimCorey
4 жыл бұрын
I will add it to the list. Thanks for the suggestion.
@ignaciolaborde9166
3 жыл бұрын
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
@JabmarMusic
7 ай бұрын
Your's course not only explains how to build a program in Visual Studio but also is a great lesson of how to speak in english. Big thanks.
@IAmTimCorey
7 ай бұрын
You are very welcome!
@Antmanzzz
4 жыл бұрын
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.
@IAmTimCorey
4 жыл бұрын
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.
@Clrscr112
4 жыл бұрын
To be honest EF most of the time is fast enough. Emphasis on the enough and not the fast. We have a fairly large system backed up by EF6 and users never mentionted anything about poor performance but to be fair we made precautions and optimised the performance heavier parts. For us the faster development outweights the performance penalty which is not a real issue (at least for us).
@IAmTimCorey
4 жыл бұрын
Yep, it all depends on circumstances. The danger will be if you get acquired and take on a large number of new clients. That can be an issue (I've seen this happen to clients). The good thing is, like you said, you've optimized the heavy parts. That goes a long way.
@andrewelmendorf2602
4 жыл бұрын
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).
@chadwad12
4 жыл бұрын
I'm watching this video as a long time user of Entity Framework (before EFCore was a thing) and as someone who successfully uses Entity Framework Core on enterprise applications that has a lot of data. I wanted to bring up a quick note though of you talking about that you "hate" how EF could technically expose your DB Credentials if you developed it on a desktop application. While that is true, I could make that argument for any desktop application that connects directly to a database. You even mentioned it in the video, that the user technically owns that one part. Any desktop application that connects directly to a database will have to somehow put username and password on the users system. Be it encrypted (and you said it, user technically owns one part of that key) and compiled into the code, it's still possible for me to mess around find it. While there are pros and cons I myself would most of the time develop a desktop application to talk to a mediator, like some kind of web API. I can manage access easier that way and can manage what is actually going in and out of my database. I could even develop some type of cache before it gets to the database, but that is whole different topic. So for most systems I end up building some mediator to talk to a desktop application, unless I am building like an offline only application. Then at that point if the user wants to "hack around" on the local db it talks to then go right ahead. So for me I guess I just don't think it's fair to just really talk about EF there. I feel any desktop application that connects directly to some remote database can have that issue, no matter what you are really using at the data access layer.
@erikverboom5383
4 жыл бұрын
My thoughts exactly! I loved the video, very educational. But as far as I'm concerned the tone could've just as easily been something like: "You want to use EF? That's cool, but this is what you need to be aware of!"
@IAmTimCorey
4 жыл бұрын
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).
@nickoaks5143
3 жыл бұрын
I understand what you mean at @15:30 about feeling weird with the Web project knowing about EntityFramework. The way I solve this is by creating a extension method in the DataAccess project (we'll call it .AddDataAccess(this IServiceCollection services) ), and then inside of this method I wire-up the .AddDbContext(). Finally, in the web project, you can simply call services.AddDataAccess() inside of the ConfigureServices, and the web project doesn't need to know anything about EntityFramework. Works great. Thanks for all of your videos!
@tomthelestaff-iamtimcorey7597
3 жыл бұрын
Thanks for the insights.
@BryanPollardPhotos
3 жыл бұрын
Thanks Tim! I wish I had this a couple years ago to share with my junior developers. I have had the same reservations as you for many years about ORMs in general. I have seen them totally derail an application once it hit production. My team used EF for the first time a couple years ago and I have been fairly happy with it, but this video pretty much sums up my feelings about it. As a hiring manager, it has been a challenge to find newer developers that can work "without the net" of an ORM. I believe that knowing how to do both is critical to being an experienced developer.
@IAmTimCorey
3 жыл бұрын
Thank for sharing from that perspective. Appreciate!
@TheMaKasss
4 жыл бұрын
I knew everything you said. But still good to know, that there are such a good tutorial for people who interested in what they are doing. Good job.
@IAmTimCorey
4 жыл бұрын
Thanks!
@acoupe1970
4 жыл бұрын
I find that data annotations are essential for getting more control on creating a model and they are easy to understand
@IAmTimCorey
4 жыл бұрын
That's good.
@aminebenhebba1891
4 жыл бұрын
I personally hate them (in general I hate anything that pollute any abstract or higher concept like Entities just for some details) prefer using Fluent API with overriding onModelCreation method and pointing to mapping classes for my entites implimenting IEntityTypeConfiguration interface. I find it cleaner and better practice. As uncle bob said : jumping from higher concept to lower ones in the same line of code is just a rude code to write. A bit like this on the PeopleContext class : protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.ApplyConfiguration(new PersonEntityConfig()); modelBuilder.ApplyConfiguration(new AddressEntityConfig()); modelBuilder.ApplyConfiguration(new EmailEntityConfig()); base.OnModelCreating(modelBuilder); }
@aliaksandrbortnik1874
4 жыл бұрын
FluentAPI gives more control than DataAnnotations. However, for stuff like simple constraints and limits, for instance, required, length and some more I prefer to use annotations to keep them right together with Entity class. It becomes reasonable in cases where there are 10+ entities in your DB.
@acoupe1970
4 жыл бұрын
Aliaksandr Bortnik I quite agree with you there, Fluent is very useful in that situation
4 жыл бұрын
Thanks for the video. You smashed it. You showed key points in terms of performance, diagnostic, debugging and others. However, I disagree in these points: 1 - if an inexperienced developer write a Data Access layer using dapper the consequences could be (IMO) 10x worse than using EF as an inexperienced developer. First, most of the time they (inexperienced devs) will handle the connection by themselves ( handling transactions, open-close dB , etc) they will create the UoW and Repo, they will do simple queries that maybe (I’m almost sure) will be not more performing than the EF ones, the data access layer will be not as tested and documented as EF, they will spent more time due to creation of all the data access layer, and more. Thus, if we compare what you can achieve as an inexperienced developer using both of the tools, I would argue that using EF can be less harmful and more efficient, than an inexperienced developer trying to create their own custom ORM or Data access Layer. 2 - In most companies there are developer team and database team. In my view devs would relegate the migration/maintenance/performance of the DB to the dB team and would work together when changes impact both sides. 3 - Premature optimisation is the root of all evil 👿. I would focus at the beginning in achieving then when performance issue are identified (hopefully, performance, loading, peek testing are done) then I would optimise the bit that cause a bottleneck (this should be done by someone with experience though) 4 - The learning curve is shorter using EF. Most .net developers will learn C# and then will learn some SQL. You could start delivering or producing work with only knowing C# and lambda expressions. However, I believe that we need more videos as the one you did, as they show a view on both worlds (C# - SQL Server) and of course learn sql as much as possible. 5 - I would consider to explain how you could change from SQL Server to another database vendor, using Dapper/EF and also would talk about how to change completely or handle different DB vendor. Cases: 1 Imagine I change the code to use only MySQL. 2 - Imagine I deploy you client with different database, ex Oracle, MySQL, Postgre DB. What would happen, what need to be done, how Dapper vs EF core or EF 6 would handle that, is that even possible or is the kind of things that you need to tell to your clients to f... up? Other than that, I love the video and I learnt lots of it. Thanks 🙏🏼
@IAmTimCorey
4 жыл бұрын
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.
@WhatIsBinary
Жыл бұрын
Tim Corey DOMINATES this market. The best quality videos. The most understandable videos. An absolute asset to YTs education sector.
@IAmTimCorey
Жыл бұрын
I appreciate the kind words.
@mhdb96
4 жыл бұрын
Man! your videos always have fully explained satisfying answers to my questions. Keep up the good work
@IAmTimCorey
4 жыл бұрын
Thank you!
@shanegray8
4 жыл бұрын
Love this. Been making similar arguments for project development for a few years. This is just explained so clearly where now I can just send a link! Good man yourself
@IAmTimCorey
4 жыл бұрын
Excellent!
@objectaware5296
4 жыл бұрын
This really doesn't explain anything other than you need to have knowledge and experience with the tools you're using. If you write poorly stored procedures (sp) or if EF does they are still poor. For example, if you don't understand that left joins pull duplicate data and write the sp then you're no better off you lack experience and knowledge. If you understand EF lazy loading then you don't need to pull the data from the address and email tables it will be done for you once the data is needed with EF.
@larsmagnusnyland9588
3 жыл бұрын
@@objectaware5296 Sometimes lazy loading can be worse than duplicating data, it really depends on which context you use it. If you use it to load thousands of people, then getting all their addresses separately that's good. However, use it in a for-loop to check some requirement for that person, or do some sort of lookup. Not good. This is because a new query is made to the SQL server for each property that is lazily loaded. And using the network card to send a request to a server, and wait for the server to do some processing, then returning a result is way slower than just reading memory. Even if the request takes 5 milliseconds, a thousand iterations on that will be 5 seconds. I'm sorry I have some trauma from when I started working a project that did this, and still does this some places.
@objectaware5296
3 жыл бұрын
@@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.
@jamesthompson2122
4 жыл бұрын
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
@IAmTimCorey
4 жыл бұрын
I am glad it was helpful.
@absentbrainded
2 жыл бұрын
This was really helpful for me TIm. I really appreciate the careful and balanced presentation on the topic. I'm an experienced SQL developer, but brand new to EF and C#. Many of the topics in this video were eye opening for me. I'm not sure if I'll have the ability to use Dapper on this client project, but you helped me at least be well aware of some of the biggest pitfalls to avoid.
@IAmTimCorey
2 жыл бұрын
I am glad it was so helpful.
@codefoxtrot
2 жыл бұрын
As of EF Core 5.0, Split Queries have been introduced to solve the cartesian explosion problem that was described in this video. This feature significantly improves single query performance, and I was happy to see it! Granted this does not solve the fundamental problem that by default, it's easy for a newbie dev to get into trouble, which is your point. Especially when I tell you Split Queries, which can be enabled globally, is by default turned off! But nevertheless, for those of us that are experienced and read documentation, EF is now extremely viable.
@IAmTimCorey
2 жыл бұрын
Yep, that's a great feature. You are right that it doesn't solve the new developer issue but having that option is really important.
@Hamza-Shreef
Жыл бұрын
Well i used to do explicit loading to solve it , don't really know if they have such feature thank you bro
@leeanderson9486
2 жыл бұрын
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.
@digitalarsenal668
3 жыл бұрын
I have watched this whole Tutorial of yours and just wanted to know if you are going to make a video on optimising LINQ Queries in the best possible way. I've also watched some of your other tutorials and they are great. Good work keep going.
@IAmTimCorey
3 жыл бұрын
I will add it to the list. Thanks for the suggestion.
@digitalarsenal668
3 жыл бұрын
@@IAmTimCorey First of all thank you for replying it's hard to reply everyone since you have a big fan following in Software Development. And second I'm not a hater of ADO but I wanted to use simplicity of LINQ with optimized Queries if possible. Even though after using some tricks like AsNoTracking() I can speed up the Fetching Queries. I need more details in this particular domain if possible. Thank you so much once again for giving us such great tutorials.❤️
@Cromfeld
2 жыл бұрын
Dear Tim! I've got a new job, thanks to Your videos! Keep up the good work!
@fiqriismail
4 жыл бұрын
Thank you for this great tutorial. Cleared a lots of doubts I had.
@IAmTimCorey
4 жыл бұрын
Excellent!
@MohammadKhanfer
4 жыл бұрын
Hi Tim, we are selling a white labeling product for many clients, each one of them has a totally different application & database version. One of the major benefits that we have in EF, as you said the tooling is great in EF, so we are using it to manage Migrations and to generate it, also we integrated that with our CI/CD so all DBs automatically using the same tooling. What is the better alternative here? What about doing CQRS and using EF for write operations at least to make things faster in development. And thank you for the great video.
@IAmTimCorey
4 жыл бұрын
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 ( kzitem.info/news/bejne/yqB6yXx9sauieGk ) and then use Dapper for data access. It just depends on the situation, the team, etc.
@SpaceShot
2 жыл бұрын
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
2 жыл бұрын
Thanks Chris. Haven’t talked to you in what seems like forever. Hope you are doing well.
@SpaceShot
2 жыл бұрын
@@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...
@ashraflambe
3 жыл бұрын
Hi Tim, thank you for great job towards C#. I was thinking that this language is losing market ground. But now with your detailed videos I changed my mind and came back. Thank you again.
@tomthelestaff-iamtimcorey7597
3 жыл бұрын
Welcome back and thanks for trusting Tim for growing your skills.
@Namynnuz
4 жыл бұрын
1:14:30 instead of .Count() == 0 it's better use .Any().
@IAmTimCorey
4 жыл бұрын
Why? The SQL command it runs is the most efficient command it can run. Is there a different benefit?
@Namynnuz
4 жыл бұрын
@@IAmTimCorey that's a better practice with LINQ overall, because implicitly it should result the same thing. But, there's difference in LINQ implementation and .Count() is kinda slow operation. I'm aware that EF mapping LINQ to actual SQL querries, but it also should convert .Any() to correct SQL form (similar to yours, which is .Count() == 0). But in every other places, it's just a better practice overall. So, to maintain consistency.
@IAmTimCorey
4 жыл бұрын
Ah, gotcha. Thanks for sharing!
@JasonDias7
4 жыл бұрын
When you use Any(). executed sql looks like this SELECT CASE WHEN EXISTS ( SELECT 1 FROM [Person] AS [e]) THEN CAST(1 AS bit) ELSE CAST(0 AS bit) END
@silverbane0069
4 жыл бұрын
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.
@lenardbartha6722
4 жыл бұрын
I like EF Core, much more than EF 6. Version 3.1 is a great improvement, just waiting for the documentation guys to catch up since the docs are still on 3.0. I think because MS is so invested in it, it has a large community and support, which is a big plus.
@IAmTimCorey
4 жыл бұрын
It has come a long way.
@roodborstkalf9664
4 жыл бұрын
They have only five or six people working on the Entity Framework team. That is not very invested in my opinion.
@lenardbartha6722
4 жыл бұрын
@@roodborstkalf9664 On github, the shows 181 contributors. Now I know not all are Microsoft employees, how do you how many are on the team? Where did you get the 5-6 people?
@roodborstkalf9664
4 жыл бұрын
@@lenardbartha6722 : They said this themselves somewhere on their github pages where they were discussing what things to prioritize.
@lenardbartha6722
4 жыл бұрын
@@roodborstkalf9664 Hmm, that is good to know.
@NoOne-oy5vs
2 жыл бұрын
Wow, this is really informative. You are correct that EF is really easy to use with many amazing query tools, code-first migration and etc. It is one of my favorite backend framework when I do project. However, I have got interned in one company that uses EF, we faced some issue with EF and some of them is what you mentioned in the video. It was years ago, we were using .net core 2.1 at that time. I am not working with them anymore, but I heard that they ended up rewrite partial of the project to optimize it. This video taught me a lot, thank you very much!!
@IAmTimCorey
2 жыл бұрын
You are welcome.
@nussberger
3 жыл бұрын
The first long video on youtube I watched from beginning to end. Worth every minute. Thank you for your hard work, smooth voice, and deep knowledge!
@IAmTimCorey
3 жыл бұрын
Glad it was helpful!
@zoltan.halasz
4 жыл бұрын
Simple, clear, easy to follow lesson on this important topic.
@IAmTimCorey
4 жыл бұрын
Thank you!
@Guacamole42
4 жыл бұрын
Awesome video! Thank you for making this one. I like EF very much. It hides the database mechanics once you have set it up correctly but when you get a problem later on, good luck with that. Great teachings coming from you about EF, I love it!
@IAmTimCorey
4 жыл бұрын
Thank you!
@keithnicholas
4 жыл бұрын
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.
@peadenl
2 жыл бұрын
Another great video Tim. I have limited experience with EF but you are 100% correct about how it will kill you in production. Also the developers will be clueless on how to fix it when you ask them why their application is running such idiotic queries. You have to try to fix issues by creating indexes and harass them to purge unnecessary data from the tables. Using stored procedures definitely provides the maximum flexibility in fixing the issues. I am going to check out Dapper based on your recommendation. Many thanks for outstanding work.
@IAmTimCorey
2 жыл бұрын
I am glad it was so helpful.
@jhtaljaard
3 жыл бұрын
A video of this quality is rare - thank you so much for this. I also learnt a lot from it. Well constructed and very clear. Thanks for covering some of the pitfalls and nuances. :)
@tomthelestaff-iamtimcorey7597
3 жыл бұрын
Thanks for watching and promoting Tim's videos.
@blogdejosemarianoalvarez6327
2 жыл бұрын
Hi Tim. Very good video. The biggest problem with the VARCHAR(MAX) or NVARCHAR(MAX) data types is that a column of these types cannot participate in an index. If you try to add a VARCHAR(MAX) or NVARCHAR(MAX) column to an index, you will receive this error: Msg 1919, Level 16, State 1, Line NN Column '' in table '' is of a type that is invalid for use as a key column in an index This prevents the use of the most important optimizations when solving queries. Indexes. So, if possible, you should always try to avoid the MAX size in Entity Framework/SQL Server and to specify the length of the columns when the data type in c# is string. I must correct you when you say that SQL Server stores NVARCHAR(MAX) data on disk instead of the database. That's not the case, SQL Server stores this column in the database. Filestream, Filetables and Remote blob store (rbs) are the ones that allow you to store large binary objects outside the database data files. SQL Server stores everything in its storage structures using 8KB pages. This is the origin of the row size limitation. The storage required for all columns in a row + the additional bytes of the structures, cannot exceed 8060 bytes (which is the size of a page - reserved internal bytes). If the VARCHAR(MAX) column fits on a single page all row data will be in that page, and if it does not fit, then it is stored within the database on additional pages linked by pointers. But everything is stored on pages in the database. Some configuration can change slightly this behavior.
@IAmTimCorey
2 жыл бұрын
They aren't standard pages. If you exceed 8k, the data is put in LOB storage, which is a different way of allocating. Basically a file system, where you have a root-level pointer that points to a set of pointers that point to the various storage locations for the data: aboutsqlserver.com/2013/11/05/sql-server-storage-engine-lob-storage/
@freerv-erveervvr
3 жыл бұрын
Hi Tim Corey, Thanks For This video, I am from Uzbekistan and i am your student! You are best teacher.
@tomthelestaff-iamtimcorey7597
3 жыл бұрын
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.
@simonlester4316
2 жыл бұрын
Thanks for making this video, was blindly using EFF Core until I watched this full video, man, what an eye-opener
@IAmTimCorey
2 жыл бұрын
Glad it was helpful!
@NavySturmGewehr
3 жыл бұрын
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.
@tomthelestaff-iamtimcorey7597
3 жыл бұрын
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 kzitem.info/news/bejne/uH2YuoFncmpemHY for a basic app with database
@NavySturmGewehr
3 жыл бұрын
@@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.
@IAmTimCorey
3 жыл бұрын
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.
@NavySturmGewehr
3 жыл бұрын
@@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.
@arpanmukherjee4625
9 ай бұрын
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.
@ankuronlyu
Жыл бұрын
Thanks Tim for this nice video, we are already using EF Core in production and in the beginning we got some performance issue but now we have optimized the LINQ query.
@IAmTimCorey
Жыл бұрын
Keep those skills up. More issues will come up, so knowing how to debug performance and improve it will be critical.
@soarwing52
2 жыл бұрын
went through the whole video and do along with it. I'm deciding whether use Dapper or EF Core in this moment, the deep analysis made a long video never felt long, all information is really valuable. thank you!
@IAmTimCorey
2 жыл бұрын
Glad it was helpful!
@sergeiarhipenko872
3 жыл бұрын
Thanks a lot for your clear pronunciation it's really easy to understand especially if you're not a native speaker!
@IAmTimCorey
3 жыл бұрын
Glad to hear that!
@saturninramirez1107
2 жыл бұрын
I'm French , and i've understnd every things you explain , THANK YOU VERY MUCH , I will start to lurn DAPPER , with yours courses
@IAmTimCorey
2 жыл бұрын
I am glad it was so clear and helpful.
@judasthepeskyjew175
4 жыл бұрын
Damn, its rare to find a creator who actually cares. Thank you :)
@IAmTimCorey
4 жыл бұрын
You are welcome.
@joshemm4991
3 жыл бұрын
I love that you spent so much time on nvarchar(max), both for reasons of encoding, storage, and searching/indexing speed. All these Computer Science topics that need time to incubate in peoples heads. Having the video digress a little is totally appropriate because this is how the programmers career goes who didn't get some intro to lower level fundamentals, so you give a good feel for the slow down that takes place. The nullable topic is also key and hard to describe isn't it? Someone needs to use this years nanowrimo to fictionalize the programmers journey.
@IAmTimCorey
3 жыл бұрын
Thanks. I would read that.
@zebcode
3 жыл бұрын
The intro is great. You set the rules on ranting etc. I like that you're somewhat critical of EF. I actually like using EF but I want a balanced opinion. I'm really looking forward to this content.
@IAmTimCorey
3 жыл бұрын
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.
@rae3430
4 жыл бұрын
First of all I'd like to say this is overall a great video exploring a lot of the questions and concerns that I (as a more advanced SQL and intermediate C# developer) had about EF and really giving a ton of incredibly valuable information. Thank you for taking the time to dive so deep on this. I'm sorry you can't make a video like this without having to constantly stop and re-defend your very reasonable opinion to a crazed comment section. My one piece of, admittedly very nitpicky, constructive criticism here is just the structure of the video kind of makes it more of a "pitfalls" video than a "best practices" video and something this long and in-depth would really benefit from some kind of timestamp guide in the description for quick reference. On my first viewing I appreciated how the lesson flowed very naturally. Unfortunately this same stream of consciousness structure makes it really difficult to actually refer back to and use any of the information here. It's really frustrating to have to skip back and forth over huge chunks at a time just looking for small pieces of information on how to avoid these pitfalls. You spend so much time detailing and re-detailing the problems in such painstaking detail that it, ironically, makes it difficult to pull your solutions and best practices out with any specificity.
@IAmTimCorey
4 жыл бұрын
Thanks for the feedback. I have students that volunteer to timestamp many of my videos, as I just don't have time. I will update the course as soon as the info is available.
@AlanDarkworld
2 жыл бұрын
So I watched the whole thing, start to finish. I've got a Java background and only recently started having a look around in C#, but since Entity Framework is like the younger cousin of Hibernate, I think I can still provide an informed opinion here. O/R frameworks like dapper skip out when you need them the most: ambient transaction management, dirty state handling, management of detached objects, second level caching, polymorphic queries and more. Sure, your app might not need any of those. But there's a reason Hibernate got as big in the Java world as it is today. You can shoot yourself in the foot just as easily as in EFCore, as was nicely demonstrated in the video, but at the same time it's a power house in terms of features. Like you said - the big earth mover. And sometimes, that trusty little shovel just isn't enough. I think it deserves more credit for that.
@IAmTimCorey
2 жыл бұрын
I agree, which is why I said so many times that EFCore as a tool is really powerful. The key is just that you need to treat it like that powerful earth mover in the fact that you cannot expect to just jump in the cab and start going, unlike when you use a shovel. As long as you understand that and don't mind learning the controls and how to use it, EFCore is an amazing product.
@gerrymacapagal1421
3 жыл бұрын
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 😃
@IAmTimCorey
3 жыл бұрын
Glad to hear it!
@cjm3801
3 жыл бұрын
Great information, Tim. Personal best practice is don’t use code first! Entity is great for help you quickly create class models and data access code but not for database creation. Thanks for all the great information as always!
@IAmTimCorey
3 жыл бұрын
Thanks for sharing!
@knitd1985
3 жыл бұрын
Thanks for the excellent video! It cleared a lot up for me. But regarding the "loosely coupled" critizism: Why not add this class to your data library: namespace Microsoft.Extensions.DependencyInjection { public static class IServiceCollectionExtension { public static IServiceCollection AddMyDataConnection(this IServiceCollection services, string connectionString) { services.AddDbContext(options => { options.UseSqlServer(connectionString); }); return services; } } } And then just call services.AddMyDataConnection(Configuration.GetConnectionString("Default")) in your frontend StartUp. This way your frontend doesn't need the EntityFramework NuGet package.
@IAmTimCorey
3 жыл бұрын
That would work. I was more commenting on what EF wanted by default. Yes, there are ways to get around that. They just aren't encouraged in demos from Microsoft.
@SolidSnake2025
2 жыл бұрын
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.
@IAmTimCorey
2 жыл бұрын
Thank you!
@pierreplourde
2 жыл бұрын
One thing missing that I was hoping would be covered is how to set up a many to many between people and addresses and between people and emails so that the linking tables get created, and how data crud would work with M:M.
@TuTAH_1
2 жыл бұрын
As a beginner developer, I was so happy that I used the Database-first approach when I saw how many problems Code-first has (But I still have been shocked with some things in a good way, like Id property has been automatically recognized as index). I'm actually don't see code-first approach have sense in *making a database*. While it's also easier using MSQLMS's diagrams with it's visual approach to create DataBase - I did the most things there and I believe it probably have ~ same amount of limitations as code-first approach have.
@IAmTimCorey
2 жыл бұрын
I'm glad the video was helpful.
@yessenzhol8989
3 жыл бұрын
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 )
@IAmTimCorey
3 жыл бұрын
Thanks for sharing!
@MrCalletennis
5 ай бұрын
If you're to lazy to use your mouse :) 00:02 Consider EF Core for improved performance 02:23 Setting up the environment in Visual Studio 08:01 Utilize string for zip codes for flexibility in address modeling. 10:59 Setting up Entity Framework with SQL Server 16:51 Configuring Entity Framework Core for SQL Server 19:09 Setting up a local DB for Entity Framework usage 23:32 Setting up Entity Framework Core Tools for Package Manager Console 26:15 Separation of concerns can prevent major overhauls 31:09 Rollbacks in Entity Framework come with potential data loss risks 33:37 Database design considerations for EFCore 38:53 Understanding model snapshot in EFCore 41:28 Unicode takes up twice as much storage as ASCII 46:35 Storage space and memory allocation implications for nvarchar(max) columns 49:09 Column type impacts memory usage and performance in Entity Framework. 54:22 Understanding one-to-many relationship in Entity Framework 56:43 Modifying tables for better design 1:01:49 Memory usage becomes a limiting factor in production environment. 1:04:10 Modifications made to models for validation. 1:08:58 Roll back in Entity Framework affects schema, not data. 1:11:15 Best practices for using Entity Framework 1:16:25 Database data loading and insertion process explained 1:19:06 Utilizing X event profiler for diagnosing EF queries 1:24:27 Entity Framework efficiently uses 'select count star' to find number of rows in table. 1:27:04 Entity Framework batch inserts without creating a stored procedure 1:32:01 Entity Framework lacks database security 1:34:23 Use of SP_ExecuteSQL for efficiency improvement 1:39:21 Using Include to fetch related data efficiently 1:41:46 Understanding batch completion and memory information retrieval 1:46:45 Entity Framework handles one-to-many relationships by duplicating the primary entity 1:49:21 Entity Framework compresses data efficiently 1:54:20 Understanding performance implications of using Entity Framework vs Dapper 1:56:31 Understanding Entity Framework migrations is crucial for application performance. 2:01:40 Entity Framework 6 doesn't alert about problematic queries 2:04:00 Utilizing toList method in Entity Framework query 2:09:21 Avoid calling C# methods in WHERE clause for better performance 2:11:51 Entity Framework provides faster development speed but may compromise on performance. 2:16:55 Entity Framework is faster to develop but can result in database performance issues 2:19:20 Optimize resource usage for cost efficiency 2:24:28 Entity Framework Core designed for loose coupling 2:26:58 Entity Framework Core is a powerful tool but requires training and experience to avoid pitfalls. 2:31:30 Consider nuanced factors when choosing Entity Framework
@Ayenam55
4 ай бұрын
Thanks
@parthbhagwat7975
3 жыл бұрын
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.
@IAmTimCorey
3 жыл бұрын
Glad it was helpful!
@kawthooleidevelopers
Жыл бұрын
Thank you Tim for this video. I have been battling with myself over EF6 and Dapper. I'll bite the bullet and go with Dapper. :)
@IAmTimCorey
Жыл бұрын
You are welcome.
@muhammadazeez2578
4 жыл бұрын
Well done, just one correction: ASCII is 128 characters (7 bits per character), and ANSI is 256 characters (1 byte per character). What you're referring to is UCS-2 which uses 2 bytes per character, so allows for about 65K characters. UTF-8 (1 - 4 bytes per character), UTF-16 (2 or 4 bytes per character) and UTF-32 (4 bytes per character) fully support unicode. Unicode has space for 1,114,112 but only has 137,000 as of now
@IAmTimCorey
4 жыл бұрын
Yeah, that's complicated. What I was trying to communicate is that if you use standard ASCII characters, they would fit in the one byte per character varchar column but if you needed to pull characters from a broader set, you would need the two byte per character nvarchar.
@quantum634
2 жыл бұрын
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.
@IAmTimCorey
2 жыл бұрын
You are welcome.
@WeijieJIN
4 жыл бұрын
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!
@IAmTimCorey
4 жыл бұрын
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.
@dimitriszafeiris6380
2 жыл бұрын
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!!!!
Пікірлер: 2 М.