0:00 / 0:00 All right.
So in the previous clip, I made the argument that testing on a live database is generally a bad idea.
And the fact that we are kind of bound to a live database here in the Singleton record finder is also
a bad idea.
So how can we get away from this?
Well, first of all, what you can do is you can simply define the database that you’re using as a dependency.
So instead of having this hard coded value here, what you can do is you can do the following.
You can make a new class, let’s call it a configurable record finder.
And this record finder can actually take as a constructor argument the database it’s going to work with.
So here I can make an I database database and then I can do Ctrl F to just initialize hopefully.
Come on.
Seriously, Ctrl F, there we go.
So I can initialize the database field and also perform some checks here which we can join using C-sharp
seven syntax.
And then what I can do is I can do exactly the same thing that we’re doing here, so I’ll just copy
and paste this over.
But instead of taking that hard dependency on a singleton database instance, what we do is we simply
say database.
So now what you can do is you can either feed the Singleton database into the constructor or you can
field your own fake database, and that’s exactly what we’re going to do.
So I’m going to make a class called Dummy Database.
So Dummy database is going to implement I database as well, but it’s going to be a dummy implementation.
It’s just going to have three elements of three cities, let’s say Alpha, beta and gamma with values
one, two and three, because their actual values don’t really matter so much.
We just want a couple of test values that we know in advance without having to go into the actual database.
So here I’ll return, I’ll make a new dictionary.
So let’s just make a dictionary from string to int once again.
And here I’m going to say that Alpha is going to have the value one and beta will have the value two.
And let’s say Gamma will have the value three.
And I’m simply going to grab from that dictionary by name the appropriate value.
So we’re simulating the database, but we’re not working with an actual database.
God forbid we actually write something into a production database.
That would be terrible.
Well, we’re not writing anything here.
We’re reading.
But it’s still expensive operations potentially.
So we’re going to use a dummy database.
And with this setup, with the setup where the database is provided in the constructor, things become
a lot easier because we can now write a more sensible test.
So we can now write a configurable population test.
And here we don’t have to deal with finding out the populations of So and Mexico City and expecting
them to be in the database.
Instead, we say var RF equals new configurable racket finder.
And here we need to specify the database.
And of course, seeing how we’re performing a test, what we can do is we can provide our dummy database
here instead and that solves the problem for us.
So once again, now what we can do is we can make a bunch of names, but we know the names in advance.
We know they’re never going to change in the actual database.
So we can take Alpha and Gamma, for example.
And then of course, we can calculate the total population as once again RF dot get total population
with the given names.
And then we know that alpha is equal to one.
We know the gamma is equal to three, so the result should be four.
And that’s what we write.
So we assert that total population is equal to four.
There we go.
Okay, so we now have this wonderful new test.
Let’s not forget to decorate it with the test attribute.
We can build everything and run this particular test and hopefully it passes.
All right.
So this is how you would typically go about it.
Now, of course, in the real world, what happens is instead of building a singleton yourself, you
quite often delegate the responsibility for having something in singleton form to the dependency injection
container.
So let’s take a look at how this would work.
Now, we’re already on our way to using dependency injection because this constructor parameter is precisely
the value that will be injected.
And the question is what does it get injected with?
So let’s go up here and instead of having a singleton database, what we’re going to have is we’re going
to have, I guess, an ordinary database.
So the ordinary database is going to have that same set of operations, except we don’t need most of
this stuff because we’re just going to have a non singleton implementation.
There we go.
So here is the public singleton database.
We get rid of instance count and we no longer have a singleton.
So just change it to ordinary database in the constructor and get rid of instance count since we don’t
care.
So it’s a simple component.
It implements a database and because it implements a database, it has to implement get population,
which once again returns capitals at given name.
And that’s pretty much it.
Now, this isn’t a singleton, but what we can start doing is we can start using it as a singleton,
provided that we use a dependency injection container framework in our application or indeed in our
tests.
So let me show you how this would work.
So let’s make a new test here.
So let’s put a test called D I population test.
Okay?
And I’ll mark it with the test attribute as always.
Okay.
So the idea here is that the database, the ordinary database is not in fact a singleton, but it gets
treated as a singleton by the entire application.
So the way this is done is you make a container builder, first of all.
Now in references I’ve got autofac.
So that’s the D container that I’m using, and I’ll also post a link to my dependency injection course
with autofac that you can follow as well if you’re interested to get more information about dependency
injection.
But basically the idea is very simple.
You make the container builder, so you say var KB equals new container builder.
And then of course we have to register the components.
So we need to be using the configurable record finder.
So I’ll say KB dot register, let’s have it registered type configurable record finder like so.
So the configurable record finder is going to be once per request effectively.
So whenever somebody wants a configurable record finder, they get a brand new instance.
But in the case of the ordinary database, we register it as a singleton.
So instead of making the component a singleton, what we say is we register type ordinary database as
an I database because remember, the dependency that we have in the configurable record finder is not
an ordinary database, it’s just an I database.
It’s a more general form.
So you can inject both the real database in here, or you can inject a dummy database.
So here what we can do is we can once again inject the ordinary database as a database.
And then here is the critical part, single instance.
So this is how you effectively tell the dependency injection container that whenever somebody asks you
for an I database.
You’re going to give them an ordinary database, but you’re going to give them that database as a singleton.
So in this kind of setup, what you’re essentially doing is you’re saying, well, the configuration
of my application is such that there is only one instance of ordinary database.
And then of course, what you do with the container is you build it.
So you say using var C equals CB build.
So you build the container and the C variable refers to that container.
And if you actually want a configurable record finder, you say var RF equals C dot resolve configurable
record finder.
And that way you get a configurable record finder whose constructor parameter because the dependency
injection framework actually finds the constructor whose constructor is initialized with a singleton
instance of a database which we have configured for our purposes to be the ordinary database here,
but it could easily be the dummy database as well.
So it’s very convenient and very easy for us to have this at the top level because then what you can
do is you can have this configuration using live data, using an ordinary database in the real world,
when you have the production application by using the dummy database, when you actually want to test
something.
And this means that there is a single point right here where you would change one to the other when
you want to test things, for example.
Play Play Play Stop Play Play Play Start Play information alert