All right, let's do it.
Let's answer your questions about the.net dependency injection service for
ASP.NET Core .NET MAUI, and so much more.
And answer the question Singleton or transient tune in
to find out which one to use.
Hey everyone.
I'm James Montemagno.
And I'm back today talking about the builtin dependency
injection service inside of.net.
Now I get questions all the time because a lot of.net Maui developers
are brand new to the built in dependency injection service we've
using as P net core for a long time.
This may be very common and familiar to.
But there are many things.
If you're just getting started with.net that are really important, which is all
about state management and what it means to register dependencies and register
them as a Singleton or a transient.
Now I'm gonna break down exactly what that means, but if you're brand new to
the.net dependency, injection service, I have great videos or write up over there
talking about all why I love it and how it works really elegantly with Donna.
Now I'm gonna use a Donnet Maui application today to demo this off,
but of course you could be using and building any Donnet application.
You could also be using other dependency injection services that are out
there, and they all have very, very similar contracts when it comes to
that Singleton transient approach.
But let's get into it Singleton.
It's a single ton.
No, it's a single, uh, basically instance of whatever you register.
If you have a page, a view model or a service, what it means is
that when you register it as a Singleton, that will be kept around.
Basically as a global in a memory.
So when you register it and you create it for the first time and you get
it back, the next time you request it, it will then go ahead and give
you the same instance of it back.
So for example, if you had increased the count of a counter to four in
some state and you navigated back and you navigated forward and you
register that view model as a single 10, you would get that same exact one.
Now on the other hand, a transient is completely opposite.
What this means is that when you register that object, whatever it
is, and you request it every time you request it, you will get a new one back.
Every single time.
So it's not gonna keep the state around.
That's really good.
If you're great.
If you're navigating to pages and you wanna pass a different object
and state around, you're gonna want to go ahead and use that transient.
But I have a good demo here that kind of walks through all the different
approaches and some sort of odd edge cases that you may not suspect.
So let's take a look.
Now I've created an absolutely astonishing looking application.
Look at it.
It has a button that says navigate.
Now this navigate is a big old button here and a Donnet Maui application.
And when you click on it, it simply goes to the counter page using shell.
Now that counter page looks like this.
It has a Don net bot on it, a count, an increased count, and
a change background button.
This counter page will come in and it does a few things.
It simply does a data binding here to the count, and then it has a button that's
gonna call the increased count command.
And then here is a button that is gonna be specific, not to the view model where
those data bindings are, but to the actual page to change the background color.
So we can see here on the code behind is that.
When we go in and create the page.
When a page is created, a new instance of it is created.
The counter view model will be automatically passed down to us.
Now that will be resolved from the dependency injection service based on
if it's a Singleton or a transient.
We'll take a look at that.
Now I have a button here that when I click on it changes the color to orange.
Boom.
And that's cool because that's gonna be to the instance of the page.
Now the counter view model that's injected is very simple.
I'm using the.net community toolkit for MVVM.
That enables me to create this observable property of count and a
relay command of increased count.
So when I click on that, it increases the count and boom, boom, boom, boom, boom.
It totally works.
Now in this instance here, what we can see is that I've registered
both the counter page and the counter view model as singletons.
So what this means is if I navigate back and I navigate forward,
Both the page and the view model are kept in state and memory.
Pretty cool.
Now let's say we wanted to change this up.
Let's say we wanted to change this to add transient for the page and this instance,
what we would expect to have happen is that every single time I go ahead and
navigate a new page is created for.
But that counter view model is a Singleton.
So it would be the same exact Singleton every single time of the view model.
So if I navigate I'll increase the count till let's say five, change
the background color, navigate back.
Now, if I navigate again, the page should be new, but the view
model shouldn't and there we go.
Background color.
Is white.
And the count is said to five because the view model was already
in that global registry and the dependency injection service.
So the dependency service automatically held onto it for us.
So there we go.
If I increase it again, go back, navigate again.
Seven, the same exact view model comes back.
Now let's do the other one here, the opposite ad transient and transient.
This is really good when you are navigating two detail pages, uh,
because you're probably gonna have the user's gonna click on different
pages and they might represent and show different pieces of data.
For example, or you might have a login pages only shown once in this
instance, we're gonna navigate, increase the count, change the
background color by navigate back.
We ideally should see a white background and count set to
zero new page new view model.
Boom.
Now here's a tricky one.
Pop question.
Pop trick question.
What happens if I do a little bit of the opposite here, I add the
counter page as a single 10, but leave the view model as a transient.
So this means every time I navigate a new counter page.
Would be created for me.
Let's take a look at that.
I'm gonna navigate increase the count change background.
Go back now here, since the counter page is a single 10, I'll get the same counter
page back, but what's gonna happen.
Am I gonna get a new view model or the existing view model?
Mm, the existing view model.
Now, the reason I got the existing view model, even though here it is ad
transient, you have to remember that that counter page was already in memory.
It was already created, already had instance to that view model.
So the constructor did not get called again.
So remember it is when you are requesting.
From these services from that dependency service, when you're requesting
something back, that's when it's gonna determine, do I create a new one or do
I return that global one back to them?
So that's the difference there?
So when should you use what.
Well, I personally like to register most things as transient.
Some people are transient, everything.
Well, it depends.
If the main part of my application is, um, tabs or a flyout menu.
I like to make those singletons, especially the ones that are gonna
be used over and over again else whenever they navigate around
or they do different things.
If they fall outta memory.
It'll have to go off, create network connection, download
stuff, back and forth.
And I don't like that.
So I register those as singletons.
Now, whenever I navigate, and it's a new page with different types of information
that I'm gonna be presenting on it.
I register those as transient.
There's a bunch of cool, uh, extension methods that you can create.
That'll sort of automatically do this stuff.
Um, there's different ways of, of really using that dependency service.
A lot of cool packages out there, but take a look at my other
videos about how I set this up.
I'll put this exact, um, demo inside of my GitHub and I'll put
links down there at the bottom.
Hope that you found this video helpful of breaking down that
Singleton versus transient problem, uh, that you may have when in doubt,
probably register a Singleton.
Um, but you know, if you are having hundreds of and hundreds of pages,
it may be best to think about.
Do I really need all 100 pages in memory all the time or just the main
ones that my users are going to use?
I said, hope this has been super helpful.
If you have any questions leave 'em below, but don't forget if
you're here for the very first.
We're here for the hundredth time.
Don't forget to hit that like button.
It super helps the YouTube algorithm of goodness, um, to recommend this
video to others here on YouTube.
And don't forget to jam on that subscribe button, cuz it notifies
you every time I put out a video, all right here on YouTube.
Hopefully you have an amazing day.
Enjoy this video until the next one.
Thanks for watching.