Sami Jaber (from DotNetGuru.org) article on lightweight containers
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:
<![CDATA[public bool Buy(SharesInfo shares)
{
Transaction tx = Transaction.Current;
// Execute against DB with tx]]>
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.
