Five Rules for IOC container

Today, I found the interesting article about 5 rules in using IOC container. And I really eager about it. In this article impressed in Service Locator is dead, and we need saying no with it. That is five rules about using IOC container:

+ Rule 1: Store in IoC container only services. Do not store any entities
+ Rule 2: Any class having more then 3 dependencies should be questioned for SRP violation
+ Rule 3: Every dependency of the class has to be presented in a transparent manner in a class constructor
+ Rule 4: Every constructor of a class being resolved should not have any implementation other then accepting a set of its own dependencies
+ Rule 5: IoC container should be explicitly used only in Bootstrapper. Any other “IoC enabled” code (including the unit tests) should be completely agnostic about the existence of IoC container

Inspite of it really old, publishing in 2009 but this article have something that I interested in. And we need make sense about Opaque dependencies and Tranparent Dependencies. What happen here if I use opaque denpendencies? It's make your class very hard for unit testing because it's seen hidden dependency class in your class. So you don't know to testing your class anywhere.In this articles of Mark Seemann, he's only showed for us about Oquaque Dependencies and he talked Service Locator is anti-pattern. But according to me, if we can use Transparent Dependencies, we can realize that Service Locator still use in the other context, and make your class don't know anything about existence Service Locator on it. In this articles, malovicn also showed for us about using internal key word for internal constructor, it's really useful for us when design the class that using Service Locator