You do realize that most efficient DI framework only inject the dependency once.
Separating Controller, Repository, and Services are good practices as well and let's be honest, we're looking at 3 methods layer at most.
Here's what happened in Java:
1. When you deploy your WAR, the DI will inject necessary component _once_ (and these components only instantiated _once_ for the whole web-app so there you go, Singleton without hardcoding).
2. A request comes in, gets processed by the pumped-up Servlet (already DI-ed). If the servlet has not been instantiated, it will be instantiated _once_ and the instance of the Servlet is kept in memory.
3. Another request comes in, gets processed by the same pumped-up Servlet that is already instantiated and has already been injected with the component (no more injection, no more instantiation, no more Object to create...)
So I've got to ask this question: what GC problem we're trying to solve here?
Some of the static methods are understandable but if Component A requires Component B and both of them have already been instantiated _once_ and have been properly wired up together, we have 2 Objects for the lifetime of the application.
I'd pay for a wee bit extra hardware for the cost of maintainable code ;)
Discipline (and knowledge of object graph) definitely help to reach to that point.
C# or Java, the whole request pipeline processing should be more or less the same. Unless one platform does things less efficient than the other.
Rails and Django do things differently as to my knowledge they do it by spawning processes instead of threads. There are app-server for Rails or Django that may use threads for efficiency/performance reason but I am under the impression the whole LAMP stack is still 1 request 1 process (even though they re-use those processes from a pool of already allocated processes).
Separating Controller, Repository, and Services are good practices as well and let's be honest, we're looking at 3 methods layer at most.
Here's what happened in Java:
1. When you deploy your WAR, the DI will inject necessary component _once_ (and these components only instantiated _once_ for the whole web-app so there you go, Singleton without hardcoding).
2. A request comes in, gets processed by the pumped-up Servlet (already DI-ed). If the servlet has not been instantiated, it will be instantiated _once_ and the instance of the Servlet is kept in memory.
3. Another request comes in, gets processed by the same pumped-up Servlet that is already instantiated and has already been injected with the component (no more injection, no more instantiation, no more Object to create...)
So I've got to ask this question: what GC problem we're trying to solve here?
Some of the static methods are understandable but if Component A requires Component B and both of them have already been instantiated _once_ and have been properly wired up together, we have 2 Objects for the lifetime of the application.
I'd pay for a wee bit extra hardware for the cost of maintainable code ;)
Discipline (and knowledge of object graph) definitely help to reach to that point.