- 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 temporary objects 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 DI Container, such as Unity, consumes no memory though. But I can't recall this ever being a problem, although its always possible that misuse of the tool (or a bug) causes memory leaks. I think you should profile the application before deciding to remove some tool that might not be the problem at all.
One common pitfall, though, is that Entity Framework's DbContext is kept alive too long (longer than a single request). If you do that, you will typically hit a myriad 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—even without using DI.
- 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 written about this subject.
- what is the purpose of having Unity, Dependency Injection ?
Unity is just one of the many DI Containers you can use when practicing Dependency Injection. Note that DI Containers are not mandatory tools. You could even consider applying DI without any tool. For small applications there is even a clear advantage in not using such tool.
But in general, where DI—as a pattern—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.
- 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 came out in 2019. I co-authored this new edition. My advice would be to read either one of these editions, and preferably the second, since it is a major upgrade.
