1) Is dependency injection really consume lot of memory ?
Dependency Injection is a pattern. The pattern by itself does not use any memory. However, you can't create loosely coupled code when implementing static classes, so during runtime class instances should be created. The amount of memory this consumes however is negligible compared to all other parts of the system, especially in a web application where ASP.NET itself creates a lot of garbage per request. And in the very rare case that you are under very tight memory constraints (which will hardly never be an ASP.NET web application), you can build up object graphs that consist of only singletons. This means objects are created once and cached, and this can reduce the amount of garbage your application creates to zero. So the use of Dependency Injection itself doesn't have to consume more memory and the difference is negligible.
That doesn't mean that a tool such as Unity consumes some memory. I've hardly ever seen this been a problem, although its always possible that misuse of the tool causes memory leaks. I think you should profile the application before deciding to remove some tool that might not be the problem at all.
However, one common pitfall is that Entity Framework's DbContext is kept alive too long (longer than a single request). If you do that, you will typically hit lots of problems, such as concurrency bugs and memory leaks. This however is not strictly related to Dependency Injection, it's rather easy to accidentally cache a DbContext for too long.
2) Advantages of having Dependency Injection ?
This is a whole topic of its own. Dependency Injection is about applying the SOLID principles, especially the Dependency Inversion Principle. The Dependency Inversion Principle is about creating loosely coupled code. When done right, this increases the maintainability of a system. Complete books are writen about this subject.
3) what is the purpose of having Unity, Dependency Injection ?
Unity is just one of the many tools to use when using Dependency Injection, but for a really small application, you could even consider applying DI without any tool. For small applications there is a clear advantage in not using such tool.
But in general, where DI helps in making your application maintainable, a DI library (such as Unity) will help in making your Composition Root (the place where you wire everything together) more maintainable.
4) How to remove this Dependency Injection from application ?
Instead of reverting back to your old practices, I think you and your team should take a step back and see this as an opportunity to start learning something new and improve your skills. There is a reason that people apply the Dependency Inversion Principle, the SOLID principles and apply Dependency Injection. It's because these practices improve the overall structure of an application and makes a system as a whole more maintainable.
It does take some time however to understand and master the concept of Dependency Injection, but IMO its time worth spent. You will improve your skills as a developer, which makes you more valuable for your company and any other company if you decide to switch jobs.
The most influential work on the subject of Dependency Injection, is Mark Seemann's book Dependency Injection in .NET. That book has had a major impact on how I and many others write code. A second edition of that book is coming out in 2018. I'm co-authoring this new edition. My advice would be to read either one of these editions, and preferably the second, since it is a major upgrade.
Dependency Injection is a pattern. The pattern by itself does not use any memory. However, you can't create loosely coupled code when implementing static classes, so during runtime class instances should be created. The amount of memory this consumes however is negligible compared to all other parts of the system, especially in a web application where ASP.NET itself creates a lot of garbage per request. And in the very rare case that you are under very tight memory constraints (which will hardly never be an ASP.NET web application), you can build up object graphs that consist of only singletons. This means objects are created once and cached, and this can reduce the amount of garbage your application creates to zero. So the use of Dependency Injection itself doesn't have to consume more memory and the difference is negligible.
That doesn't mean that a tool such as Unity consumes some memory. I've hardly ever seen this been a problem, although its always possible that misuse of the tool causes memory leaks. I think you should profile the application before deciding to remove some tool that might not be the problem at all.
However, one common pitfall is that Entity Framework's
DbContextis kept alive too long (longer than a single request). If you do that, you will typically hit lots of problems, such as concurrency bugs and memory leaks. This however is not strictly related to Dependency Injection, it's rather easy to accidentally cache aDbContextfor too long.This is a whole topic of its own. Dependency Injection is about applying the SOLID principles, especially the Dependency Inversion Principle. The Dependency Inversion Principle is about creating loosely coupled code. When done right, this increases the maintainability of a system. Complete books are writen about this subject.
Unity is just one of the many tools to use when using Dependency Injection, but for a really small application, you could even consider applying DI without any tool. For small applications there is a clear advantage in not using such tool.
But in general, where DI helps in making your application maintainable, a DI library (such as Unity) will help in making your Composition Root (the place where you wire everything together) more maintainable.
Instead of reverting back to your old practices, I think you and your team should take a step back and see this as an opportunity to start learning something new and improve your skills. There is a reason that people apply the Dependency Inversion Principle, the SOLID principles and apply Dependency Injection. It's because these practices improve the overall structure of an application and makes a system as a whole more maintainable.
It does take some time however to understand and master the concept of Dependency Injection, but IMO its time worth spent. You will improve your skills as a developer, which makes you more valuable for your company and any other company if you decide to switch jobs.
The most influential work on the subject of Dependency Injection, is Mark Seemann's book Dependency Injection in .NET. That book has had a major impact on how I and many others write code. A second edition of that book is coming out in 2018. I'm co-authoring this new edition. My advice would be to read either one of these editions, and preferably the second, since it is a major upgrade.