>> 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.
[MUSIC]
>> Hi, welcome to Visual Studio Toolbox.
I'm your host, Robert Green and joining me Phil Japikse.
>> 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 this.
Thanks to all the viewers who are 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.
>> Yeah. We're talking
Entity Framework Core those WPF work with.NET Core?
>> Absolutely. WPF isn't.NET Core now with 3.1.
But even EF Core worked with WPF prior to WPF being in.NET Core.
So we used EF Core for all of our data X.
Once, he have core hit 2.1, we use it everywhere.
So in our WPF apps and our.NET Core or ASP.NET Core apps.
So 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.
So the problem with the early versions of
EF Core and even the later version is a EF6.
When an object is reconstituted
from the database by entity framework,
it's calling into the centers.
So what is really happening?
So a command objects 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.
Then you're setting the blog URL and
the blog name from this data reader,
and prior to this change,
it was using the center to call into it.
So let me just show my screen so I can put up
an example of what we're talking
about just from the entity standpoint.
So let's look at this blog thing here.
So 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.
There's two things.
It sets the IsDirty property to true.
>> Okay.
>> A lot of times in WPF will do that because we can
bind properties of UI elements to properties on the model.
So for example, if is dirty equals true,
then we'll enable this save and cancel button's.
>> Exactly.
>> Otherwise, we don't.
>> Yeah. Standard pattern.
>> Standard pattern, and I think
my silly little thing does is just write out to the console,
so we know that the event was fired.
So what we had to do in EF6 was
we'd look for the object
materialized event when that event gets fired,
that was immediately after the object was created in code,
and then we would mainly set
the is dirty 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 there's a whole check the documentation for all the caveats.
Because you don't have to have matching names,
you can specify things and configuration and mapping
much more than we want to go into
this show as 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,
lowercase, right, 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 the center.
>> Okay.
>> So you don't have to worry about doing
any magic to make sure that those events are being fired,
because what we dont want to do.
>> So you don't call. The first time you
retrieved something or created,
you don't need to fire off
property changed for every single property?
>> Right, correct.
>> Got it.
>> So let's look at the demo code here.
So I've got a set here
and I create a new instance of
the blogging context because I want to make
sure that we're not carrying anything in the change tracker
from run to run to give us a false positive or false negative.
So I'm going to set properties through C-Sharp.
I'm going to set these two properties right here.
What we'll see is that it is set to dirty
and the property changed message will come up on the screen.
We'd save the changes, now it's in a database.
We created new incidence at a blogging
context-based but she just flushing everything out.
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.
>> So let's run this.
There's a lot more to this feature that when I'm
talking about here, but reality,
this is the part of the feature that I use,
because we still do some WPFs.
So all of our shop for 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 WPF in.NET Core.
I'm sure will be, I just don't know that I forget now.
So there I set the properties through code.
I got my two property change events
because they've got two properties.
So behaves as we expected.
You want it, if you're changing, through 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 blogs or to buddy 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 IsDirty is true,
I said that backwards.
So here's what I did,
We'll keep this, but let me explain to you what we did.
>> He change IsDirty.
So you never seen a backing field for IsDirty?
>> I never said that backing field for IsDirty. That's true.
>> You set it for the other ones.
So you proved the point.
>> I proved the point, yeah.
>> A bit more detail than you
originally intended, but that's cool.
>> Yeah. I did keep.
Actually, I've proved the point a lot better at my
expected threw 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 center that you don't want to
happen every time you reconstitute.
That's really the, the main purpose of that I see for this.
The main use that I have for this is to help me keep
my notify property changed
event handling of that pattern
nice and clean even when using EF Core.
>> Right. Cool, nice feature.
>> Yeah.
>> All right. So again,
that's a wrap on this series.
>> Yeah.
>> Thank you so much for doing this.
Thank you everybody for watching.
If you have ideas and why you'd like future series to hold,
let us know, we'll see.
>> Yeah.
>> We will see you next time on Visual Studio Toolbox.
>> Thanks for watching
[MUSIC]