Sami Jaber (from DotNetGuru.org) article on lightweight containers

Note: this entry has moved.

Half the article is almost a straight copy of topics covered by Fowler's article. Trivial renaming is done to shadow this fact, basically replacing Fowler's MovieFinder example with BusinessObject one, which supposedly should be more attractive. And you only realize this if you read it entirely, and right at the bottom, find the link to Fowler's work and go read it (you realize in the first page if you already did, like myself).

He partially cites Fowler:

Martin Fowler's argument against this (Service Locator) pattern is its inaptitude to adapt to mock objects (for unit testing).

This reference is clearly distorted to make the previous discussion about Dependency Injection appear as supported and encouraged by Fowler. Initially, Fowler says: 

A common reason people give for preferring dependency injection is that it makes testing easier. The point here is that to do testing, you need to easily replace real service implementations with stubs or mocks.

Inmediately after, he states *his* view on the matter:

However there is really no difference here between dependency injection and service locator: both are very amenable to stubbing. I suspect this observation comes from projects where people don't make the effort to ensure that their service locator can be easily substituted.

Which is absolutely unquestionable.

The article is unnecessarily really hard to follow. The author makes too many assumptions in order for it to be understandable. For example, he assumes the reader is familiar with PetShopDNG. He makes a strong assertion like the following:

To summarize, the Abstract Factory and the dynamic code instantiation are a poor relation of the IOC approach. Why should we manage the life cycle of a dependency where an intermediary object could do it ? On another hand, if some techniques like code generation (AOP) allow to insert a behavior between client and provider, IOC gives a similar result with less effort.

Without clarifying a bit of it in the following paragraphs. He also says

When .NET IOC Frameworks will be ready (that's to say in some years ;))...

Well, as I showed in my previous article, the building blocks are in-place already, if you follow the ComponentModel architecture.

He shows an example where a class accesses a transaction object by using Transaction.Current:

This is a very common approach in .NET, and it appears to be the one Indigo will be encouraging. The first drawback is that being a static property call, Transaction must be a specific implementation, not an interface. This was solved in ASP.NET Whidbey providers by having this class and its static members be just proxies on a concrete implementation instantiated as a singleton depending on config. The main drawback, however, is that if many services are potentially available, having [Service].Current for each of them makes for a highly descentralized service management. There's no way to administer, configure and provide all these services in a single place, therefore, maintainability and testability are hurt.