Now the next thing which we are going to learn right now is something which is the one of the most important topic of C sharp. I'm sure that if you have faced in the interview, which is based on C sharp, then somebody has obviously asked you these questions regarding inversion of control, which is known as IOC, and dependency injection. And that's what our topic for this video series. Now. Now, in this case, as I said, IOC stands for inversion of control and they something is known as di which is dependency injection. Most people have some idea about this, but they have always some confusion about this too.

That's why I have decided to cover this thing in this particular course. Now before we cover this two points, I just wanted to remind one thing that there is something which is known as D IP. And you guys already know this thing as we know we have five solid pieces Suppose this was the last and final principle of solid, which was the dependency inversion principle. In this video series when I have covered dependency inversion principle, in that particular video, I have not explained dependency inversion principle fully. And there was a reason behind that, because you're not able to understand dependency inversion principle. Without these two things, which is inversion of control and dependency injection.

That's the reason Now it's the time to understand dependency inversion principle with these two terms. And we are going to again, do this thing with Cole just to understand these two concepts properly, and to to create very basic example first in my Visual Studio. So let's go ahead with that, I have created a new console application within the employee management. And inside this I do not have any code right now. And now we are going to create a new class inside this. So I'm adding a new class and I'm giving the name of this class, let's say employee.

So this class employee is going to be the first and very simple class of this application, I'm going to make sure like always that this class is going to be public. And inside this employee class, I have a very simple method, which is void, add. So it's something like this, that I have a method which will help me to add a new employee inside this. And I should have some logical code inside this add employee. But because this is a normal basic application, I'm assuming that this application is also going to have some database associated with that. And to deal with this data, which we are going to store with respect to employees, we have two different data sources available for us.

Let's say I'm going to add a new class. My first data source, which is associated with my project is based on SQL. So I'm giving a name of the class SQL data access layer. So this is my class, which is SQL data access layer. And then I'm going to add one more class name of this class I'm going to give Oracle. As we know, it's possible that we are going to have two different data sources associated with one project.

So, we have one which is SQL and another one which is Oracle data access layer. Once we have this two kind of classes, now, when we are going to add a new employ, we are going to create either object of SQL data access layer or we are going to create object of Oracle data access layer. And based on that we are going to add a new employ. That's what the goal is. As we know, as for the dependency inversion principle, if I create an object of SQL data access layer or Oracle data access layer inside employee class, I can associate any of the methods of these two classes but that is something which is known as tightly coupled and that's why we should not do that thing. So like always, when we want to do dependency inversion principle, we are going to add a new item which is going to be an interface.

And this interface is going to work like an abstraction between my both the data access layers. So I'm giving the name of the interface idelle. And the moment we are done with this, this public interface, which is the name idelle, is going to have one method inside this, which is add. Because this is the interface, we are not going to have a logic inside this method. But we know that interfaces are always going to have a public methods inside that so we have an add method inside this. And now it's the time we are going to implement this interface in our both the data access layers.

So the moment I implement this interface, I'll get the method add. And inside this we have to write the logic. So let's say this is going to be an add logic with SQL data source. We have to add logic but right now I'm not wasting my time in adding this logic and dealing with the database Operations because we all know that thing. And same with my Oracle Dell is also going to have idle implemented inside that and using that this is going to have another logic we are able to add employ using this, but this is going to be an add logic with Oracle data souls. So they are assuming that we have one interface which is working as the abstraction.

And then we have two different concrete implementations of this. And once we have these two different concrete implementations, we can use any one of this inside the employee class with the help of this ideal to understand this thing properly inside this, I'm going to add a new private variable of ideal. So after defining private, which is a variable is going to be of type idle, and I'm getting an email this variable underscore So, this is my One of the private variable of that particular interface inside this. And after this, I'm going to create a constructor. So I have a public constructor with me, which is for this class employ. And this constructor is going to have one parameter of maybe a type Delta type.

So this is going to be an integer parameter of type Delta. And based on this integer parameter, I'm going to decide whether I'm going to associate with SQL data source or Oracle data source. So I am just going to write a simple logic inside this like if delta type is equals to equals to one. Then I'm going to specify that this underscore del is equals to new SQL. So it's going to associate with this particular class instance at that time Now, we are going to specify one more statement which is else. And if any other value we have given in delta type, then we are going to associate this underscore del equals to new Oracle.

The moment we do this, it's something like we are deciding whether we are going to associate with SQL data access layer or Oracle data access layer based on this parameter will util type. Now, up to this point, what we have done, we have employee class which is connected with I data access layer, which is my interface. And that's why this thing which is employ is actually connected with Oracle and SQL data access layer. But it's not connected with this two and the tightly coupled way it is connected in a loosely coupled way. But there is one small problem. Now assume if I want to create object of this employ, and I want to call this thing, let's say I'm going to my main method of a program class and I'm We're going to create an instance of an employee class.

So I'm creating employee OBJ equals to new employ. And the moment I do this inside this employee, I have to pass a parameter. Now let's say if I pass one, then this is going to associate with SQL data access layer at runtime. And that's what the dependency inversion principle is also associated with, we know that the coupling between two different objects should be loosely coupled. And the injection should happen at runtime. So while creating instance of employ when I pass this one is going to associate with SQL data access layer, and not have a method for the ad, and inside this we have to associate that underscore del.ad.

And the moment we do this thing is actually going to call that particular method inside this and that's why I'm just specifying this public void ad. Once we are done with this, if I go back to this, and now if I do OBJ dot add is going to call specific method based on SQL data access layer. Now, the question is right now if I run this application is going to work very well is going to associate with my employee class instance and employee class is going to associate with either SQL data access layer or Oracle data access layer. With the help of interface it will now as for the dependency inversion principle, we have done everything similar to what we have done in that video. But there is one small problem in this and that's where this particular term will come into the picture, which is known as inversion of control.

Right now, if we focus on all the principle of solid, the principle number one says that every class should have a single responsibility. Now right now, if you check this employee class is responsible for adding an employee as well as maybe some other operations which are associated with the employee. But there is one extra responsibility which we are adding into this employee, which is not a concern of employee class. If we have an employee class, it should associate With maybe operations like add, remove and some other things, but associating with which data is clear, this is not a work of employee class, this should be shifted to somewhere else. And that's what inversion of control is saying. Right now, if you check the program class, this program class and employee object is totally depended is totally dependent on the employee class.

An employee class is dependent on data access layer classes, either SQL data access layer, or Oracle data access layer is actually tightly coupled, even though we have used interfaces. And that's why this is something which is not the right way to do dependency inversion. And inversion of control is saying that we have to shift a control of this particular mechanism, not into the employee class, but we have to shift this thing into somewhere else. And that's where we have a term inversion of the control so we are actually shifting this control to somewhere else. Now, if I want to shift this mechanism to somewhere else, first I have to change this logic. And to do that thing, I'm going to remove this.

And I'm just going to put one variable, which is of type idle. So I'm defining idle, which is actually a Dell parameter of my constructor. And I'm simply specifying that whatever is coming into that dough, we are going to assign to our private variable, which is idle. So it's simply the value of the parameter is assigned to the private variable. And using this private variable, we are going to call them a thread. But the question is now I don't know which particular data access layer we are going to call or we are going to associate with either SQL data access layer, or Oracle read access layer at runtime.

We don't know from this class. And actually, that's not a concern of employee class. Employee class is only concerned about adding a new employee, which data access layer we are using, it's actually should be controlled by some other party or some other thing. And that's what we can control anywhere but outside the employee class. To do this thing, I'm just going to my program class. And now this is not going to take this one inside this simply specifying that we are going to create an employee object.

And while creating employee object, I'm going to specify here only that this is the instance of SQL data access layer. Now similarly, when I do this thing, it's actually going to associate with s3 data access layer. Or if I want to associate with Oracle data access layer, I can do with both. And with both, when I'm going to call this objects is going to show me that it's going to work with both the data access layers, and it will work at runtime either with SQL translate or with Oracle data access layer. And that's why this is a right way of doing dependency inversion with inversion of control. Let me tell you one thing in this one simple sample.

I've actually covered three different terms. Right now as per the structure, we have this interface and the dependency between employee class and I data access layer is Totally loosely coupled. And that's what dependency inversion principle was seeing at that time. So, we have verified dependency inversion principle, with that we are satisfying single responsibility principle also. And because we have shifted the controlling mechanism of data access layer to outside employee class, which is inside this program class, then this this mechanism of deciding which access layer we are going to use is shifted and that is where inversion of control has taken place. So, we have shifted the control to the main method, and that's where we have inversion, inverted that control.

Now, the way we have done all this thing right now is something which is known as dependency injection. Just to remind you, inversion of control can be done by number of different ways. We can achieve same kind of thing with events, we can achieve same kind of thing with maybe properties. And when we do that thing, there are different ways but the one which I have done right now is something which is known as dependency injection. So we are injecting the dependencies of either this or That data access layer into the constructor of our employee class and based on that we are able to associate with that. I hope you're able to understand this simple video.

Thank you