I ended using "your laws" in background by digging into the SOLID code principles, where eventually you'll end with constructors having resolvable parameters (of their dependencies) passed by interfaces, on which instantiation you’ll chose some IoC/Di container to easy your life…(writing new (new …(new…) at top of your call just doesn’t make sense)

All of this wouldn't be needed, if coders would follow SOLID (code to abstractions rather than to implementations etc..) from the start of a Greenfield project, but I understand we live in a real world…

It needs explanation and big attention once project is heavy in production and refactoring  (due to bad coding practices) has become inevitable…

Once again, thank you very much for your time and evangelism to good code practices, hope Joel would listen x)

As for var logger  = new Logger(); you can do that even in this example (logger is not having any dependencies) but that is corner case (in this discussion)

There are two major reasons why you may consider using the this.container.Resolve (container is the Facade you mention):

1. You have in real world quite often this case

ClassA depends on ClassB

ClassB depends on ClassC

ClassC depends on ClassD

If you follow the rule of explicit ctor dependencies (law #3) you would end in your code (if you don't use the container to resolve with this)

new ClassA(new classB(new ClassC(new ClassD()))))

Which violates the encapsulation by leaking the internals of the class B to place where class A is consumed

Another variation of this problem can be seen if you imagine that the dependency class depends on IOC service in which case you end with

new ClassA(container.Resolve<ISomething>())

There are ways you can go around this: poor man dependency injection, opaque service locator etc but as my blog posts show I'm not very fond of them based on my past experience in using them.

2. Opaque introducing of AOP

Every IoC major container has interceptors which allow you adding aspects upon resolution enabling very interesting combinations (check out Ayende’s example http://tinyurl.com/eventbrok))

3. SoCSRP etc

Let IoC container do what he is supposed to do (building the object graph in this case) and our entities to do what they are supposed to do (business logic only)

As for the inheritance scenario (Logger, EmailLogger etc) I have in my queue already a blog post showing my take on that (IoC combined with attributed ctor parameters)

If you are building dll that someone else will consume

for example is much cleaner to have

{

Bootstraper.SetUp();  

UserRepository userRepository = new UserRepository();  

userRepository.Delete(3);  

}

and not use any IOC container.

And if you are building classes that some other programmers will consume is much better to have Facade pattern rather than having dependencies in constructor.

For example if I have class for Logging errors that log error in Database, send Email to developer and log error in text file I think that is much better to have call like this without any call to IOC container:

Bootstraper.SetUp();  

ILogger logger=new Logger();

logger.Log("error message");

rather then

Bootstraper.SetUp();  

IContainer cont = UnityContainer.Instance();  

ILogger logger=unityContainer.Resolve<Logger>();  

logger.Log("error message")

On the other hand I will create classes on lower levels like

DatabaseLogger or EmailLogger same way that you have described here if they have some dependency classes.

What do you think?

How would you handle the scenario when your business class/entity wants to create another business class on its own? It would still be coupled with the container since you would have to create/resolve this new class through the container.

Would some sort of aspect framework be better for initializing new entities, can it even be done?