Jerarquía de contenedores de Inyección de dependencias en ASP.NET MVC

¿Has tenido alguna vez un sistema de información; cuya interfaz para la parte interactiva es ASP.NET MVC; que necesita mantener varias versiones de comportamiento en la capa de aplicación y/o negocio a la vez y la decisión de qué versión utilizar tenía que establecerse en tiempo de ejecución según el input del usuario? Si es así, quizás esto te interese.

La inyección de propiedades es el mal encarnado.

En StackOverflow no paro de encontrarme a gente preguntando como se realiza la inyección de dependencias en las propiedades, en vez de en el constructor, de una clase con tal o cual contenedor.

Las putillas kármicas que quieren puntos de reputación sin importarles lo demás un carajo se dedican a poner las 4 líneas de código de turno y se llevan sus 15 puntitos calentitos.

Yo, a costa de no recibir puntuación ninguna, prefiero responderles con ética y plantarles un "WRONG WAY, TURN BACK!!" bien gordo al principio de la respuesta y luego una extensa explicación que nadie se preocupa en leer.

Resolver funcionalidades transversales sin Programación Orientada a Aspectos.

A mi me encanta la Programación Orientada a Aspectos (AOP). De hecho, la he aplicado exitósamente para gestionar la seguridad y el registro de trazas en varias aplicaciones utilizando mi librería AOP favorita en su version gratuita: PostSharp. Esta librería se encarga de inyectar el código de los aspectos en los ensamblados (Compile-Time Weaving) por lo que, al no funcionar sobre objetos virtuales, clases proxy y cosas por el estilo, no sufre de la problemática de otros frameworks AOP que obligan a limitar las formas de declarar las clases.

AOP es la mejor manera de gestionar y estructurar las funcionalidades transversales (cross-cutting concerns) de una aplicación; desgraciadamente está muy poco extendido y se está haciendo difícil adoptar estas tecnologías por parte del 'mainstream' del desarrollo de software (al menos en esta España garbancera).

Cuando un jefazo ignorante no me permite utilizar AOP para las funcionalidades transversales tengo un plan B que funciona a las mil maravillas: Usar un patrón decorador y construir una cadena de responsabilidades con la inyección de dependencias.

Arquitecturas débilmente acopladas.

Conseguir una arquitectura cuyos módulos tienen un acoplamiento débil no consiste sólo en crear una interfaz por cada clase existente y consumirla. Voy a intentar reproducir el proceso mental que yo sigo para llegar a este objetivo. Espero que esto sirva, a futuros lectores, para ayudarles a "cambiar el chip" a la hora de diseñar los módulos de un sistema de información.