Refactoring to improve maintainability & blendability using IoC part 2: Reducing IoC container coupling

Recap of part 1

In part 1 of this series we started reducing the Service Locator calls by removing them from the view models and moving it to the ViewModelFactory since this class is responsible for creating the view models. This allowed us to cut the ties in the view models where they were requesting dependencies from a global container.

Some of the benefits we gained from the first iteration of refactoring:

    Reduced coupling between view models and the IoC container.
    View model dependencies are push not pull. This removes coupling between the view model and the source of the dependencies.
    View models are more intention revealing. What view models depend on and require is explicit and not hidden.
    View models are easier to test. An IoC container isn’t required to initialize a unit test.

After all of the changes in the first iteration we still retained Blendability and did not have to compromise the design time experience.

This still left us with a global container which the ViewModelFactory calls to resolve dependencies for view models. Once our view models were up and running again it was time to remove the global container and dramatically reduce the coupling.

Why a type asking the IoC container to resolve its dependencies is bad

Having view models use a Service Locator or request the IoC container to compose the dependencies on its behalf couples the view model to the source of its dependencies. The view model does not need the IoC container itself to do any work. It only needs its dependencies. The view model requesting the dependencies has created a requirement on the view model for the IoC container to exist although it is not needed when you look at what the view model is responsible for.

Read more: kellabyte
QR:

Posted via email from Jasper-net