 On today's Visual Studio Toolbox, we wrap up our series on EF Core in depth, and Phil shows us a neat feature called Field Mapping. Hi, welcome to Visual Studio Toolbox. I'm your host, Robert Green, and joining me, Bill Jepixi. Hey, Phil. Hey, Robert. This is it. This is episode 10, and the last in our Entity Framework Core in-depth series. I want to thank you very much for doing these. Thanks to all the viewers for watching these and indulging us. What are we wrapping up with today? We're going to wrap up with a feature that really comes in handy if you're doing, for example, WPF or you've got some change tracking that you want to implement. WPF. Hey, we're talking Entity Framework Core. Does WPF work with.NET Core? Absolutely. WPF. Is in.NET Core now with 3.1, but even EF Core works with WPF prior to WPF being in.NET Core. We used EF Core for all of our data acts. Once EF Core hit 2.1, we use it everywhere, so in our WPF apps and our.NET Core or ASP.NET Core apps. Let me frame the problem. The problem is very simple. If you're doing I notify property change, that pattern means that whenever a property change, you notify people, not people necessarily, but things, you raise an event. The problem with the early versions of EF Core, and even the later versions of EF6, when an object is reconstituted from the database by Entity Framework, it's calling into the setters. What is really happening? A command object is created, connection is used, a data reader is loaded up, and from that data reader, reflection and the mapping and everything else is used to rebuild these.NET objects. But what you're doing is you're doing blog equals new blog, and then you're setting the blog URL and the blog name from this data reader, and prior to this change, it was using the setter to call into it. Let me just show my screen so I can put up an example of what we're talking about just from the Entity standpoint. Let's look at this blog thing here. I've got, this is a pretty standard pattern where if the value has changed, then I raise an event. In this silly example, I'm just calling a method. That does two things. It sets the isDirty property to true. A lot of times in WPF, we'll do that because we can bind properties of UI elements to properties on the model. For example, if isDirty equals true, then we'll enable the save and the cancel buttons. Exactly. We don't. In the standard pattern, I think my silly little thing does is just right out to the console so we know that the event was fired. What we had to do in EF6 was we'd look for the object materialized event. When that event fired, that was immediately after the object was created in code, and then we would mainly set the isDirty flag to false and all the objects. It was a pain, but it worked. What's much better in EF Core is EF Core now will use if it can find it, and check the documentation for all the caveats, because you don't have to have matching names. You can specify things in configuration and mapping, much more than we want to go into this show. I just want to get to the basics. If you've got a property that has a backing field that is named similarly, in other words, underscore, lower case, something that fits within the convention, then EF Core will actually, even though it's private, will use that backing field to reconstitute your object instead of using this setter. You don't have to worry about doing any magic to make sure those events aren't being fired, because what you don't want to do. The first time you retrieve something or create it, you don't need to fire off property change for every single property. Right. Correct. Got it. Let's look at the demo code here. I've got a set here, and I created a new instance of the blogging contest, because I want to make sure that we're not carrying anything in a change tracker from from run to run to give us a false positive or false negative. I'm going to set properties through C-sharp. I'm going to set these two properties right here, and what we'll see is that it is set to dirty. The property change message will come up on the screen. We saved the changes. Now it's in the database. We created a new instance of the blogging contest by she just flushing everything out, and we're going to get the blogs, and we're going to print them out, and we will never see the property change message on the screen. Got it. Let's run this. There's a lot more to this feature than what I'm talking about here. But in reality, this is the part of the feature that I use because we still do some WPF. All of our shop floor automation work is done using WPF. We're moving it to WPF 3.1. I don't have enough information yet to tell you whether I'm happy or not with the WPF in.NET Core. I'm sure I will be. I just don't know enough yet now. There I set the properties through code. I got my two property changed events because I got two properties. So behaves as we expected. You want it if you're changing it through your application, you want to have that notification. That's the whole purpose of doing the pattern. So now I'm going to set the properties through the EF materialization. So I'm calling blogs, get all the blogs, or the body URL to list. What you'll see is no property changed event. Let's just loop through all of them. We'll run down to here, and we have the properties output. Is dirty is true. I set that backwards. So here's what I did. This is totally all right. We'll keep this. But let me explain to you what we did. You changed is dirty. So you never set a backing field for is dirty. I never set a backing field for is dirty. You set it for the other one. So you proved the point. I proved the point. A little bit more detailed than you originally intended, but that's cool. Yeah, actually I proved the point a lot better than I expected through me off a little bit. But you know what? This is sort of live, but it worked. So yeah, and again, if you're just doing straight ASP.net core, building services, things like that, you probably don't care a lot about this feature. You might want to take a gander. If there's anything that you need to do in your setter that you don't want to happen every time you reconstitute, that's really the main purpose that I see for this. And the main use that I have for this is to help me keep my notify property changed event handling and that pattern nice and clean even when using EF core. Right. Cool, nice feature. Yep. All right. So again, that's a wrap on this series. Thank you so much for doing this. Thank you everybody for watching. And if you have ideas on what you'd like future series to hold, let us know, we'll see. Yep. And we will see you next time on Visual Studio Toolbox. Thanks for watching.