La mejor manera de hacer programación orientada a aspectos en .NET es utilizando técnicas de diseño bien conocidas. Por ejemplo, al aplicar los principios SOLID puede lograr la flexibilidad y modularidad que necesita para permitir agregar preocupaciones transversales. Si tiene el diseño correcto, incluso podrá aplicar la mayoría de las preocupaciones transversales sin ningún marco. Es una falacia pensar que la POO no es adecuada para hacer AOP.
Aquí hay algunos consejos:
- No dependa de instancias concretas, sino que dependa de abstracciones.
- No mezcle preocupaciones transversales y lógica empresarial en la misma clase.
- Agregar preocupaciones transversales al envolver clases con lógica de negocios en clases que implementan esas preocupaciones ( decoradores ).
- Encuentre artefactos comunes en su diseño y modele por igual, preferiblemente usando el mismo tipo de abstracciones. Mire esto y esto, por ejemplo.
Cuando tiene las abstracciones correctas en su lugar, agregar nuevas preocupaciones transversales al sistema es solo una cuestión de escribir una nueva clase de decorador y envolverla en las implementaciones correctas. Si las abstracciones son genéricas, puede envolver un solo decorador alrededor de un gran grupo de clases (que es exactamente de lo que se trata AOP).
Aunque las técnicas como los proxies dinámicos y el tejido de código podrían facilitar el trabajo con una aplicación mal diseñada, realmente no hay alternativa para un buen diseño. Tarde o temprano te quemarás. Sin embargo, esto no significa que no se deba utilizar la generación dinámica de proxy y el tejido de código. Pero sin un diseño de aplicación adecuado, incluso esas técnicas serán de utilidad marginal.