He's actually managed to create a container by using the variable scope of the App class. That'll work fine for awhile, but it doesn't scale particularly well.

He's actually managed to create a container by using the variable scope of the App class. That'll work fine for awhile, but it doesn't scale particularly well. You also lose lifecycle management (in his example, everything is a singleton) and lazy instantiation. Also, you lose the ability to isolate dependencies on external libraries to separate assemblies -- in this case, the main assembly needs to know everything about everything. I'm biased (I wrote a DI framework for .NET), but I don't really understand what people think they're gaining by avoiding the use of a container. The complexity of dependency wiring increases geometrically with the size of your application, and I personally would like as much of that complexity hidden as possible.