ventas ventajas programming programacion paradigma oriented orientado orientada example desventajas caracteristicas aspectos .net aop

.net - ventajas - programacion orientada a aspectos spring boot



Ayuda e informaciĆ³n sobre la programaciĆ³n orientada a aspectos (5)

Soy un recién llegado a la idea de programación orientada a aspectos, pero me gustaría explorar la idea de usarlo en mi proyecto para manejar el registro, informes, etc. Para este fin, tengo algunas preguntas:

  • ¿Debería molestarme en explorar este camino de AOP para estos propósitos limitados?
  • ¿Qué Frameworks .NET que soportan AOP están disponibles?
  • ¿Cuál de estos marcos admite una interfaz fluida? (Odia la configuración XML) :)

AOP es interesante para mí también. Me parece que el registro y la supervisión del rendimiento, la generación de informes es mucho más de lo que AOP está diseñado para manejar. Para .NET, Post Sharp es un muy buen marco para AOP.

Solo he experimentado un poco pero parece muy bien implementado.


No pienses que es algo totalmente diferente. AOP mejora (IMO) su diseño reduciendo el acoplamiento, aumentando la cohesión, separando las preocupaciones dando a un objeto de cierta responsabilidad única de tipo 1. Si eres de .net world PostSharp utiliza atributos personalizados para tejer consejos. Si eres del mundo de Java, puedes usar la extensión de Java llamada AspectJ . AOP tiene más aplicaciones de las que ves en general.


No puedo hablar sobre los detalles de .NET, pero AOP y la idea más general de poder adjuntar ganchos a métodos arbitrarios, es una técnica útil que puede resolver algunos problemas peludos.

Un ejemplo es el diseño por contrato . Digamos que tiene un montón de métodos sobre los cuales desea aplicar algunos contratos comunes. Puede agregar algunos "consejos" (el término AOP) antes y después de llamar a cada método sin tener que cortarlo y pegarlo en cada método.

Mientras prueba, a menudo es útil saber qué está pasando en algún método interno. Cuántas veces fue llamado y tal vez lo que devolvió. Puede agregar un aspecto para hacer esa monitorización sin tener que agregar un código de prueba que distraiga al método en sí. La edición del código para ese método podría no ser posible.

Solo ten cuidado con la forma en que se implementan los aspectos. Algunas implementaciones son elaborados preprocesadores que pueden hacer que la depuración de su código sea más complicada. Otros se conectan sin problemas al lenguaje. Los lenguajes dinámicos manejan AOP muy bien. Perl tiene Aspect.pm para AOP y el más general Hook :: LexWrap para lograr ganchos de método.


Si va a mirar Post Sharp, puede descargar Google Book Downloader de CodePlex. Creo que este proyecto lo usa


La Programación Orientada a Aspectos es mucho más que simplemente iniciar sesión, informar etc., como verá si echa un vistazo al sitio web de PostSharp. Personalmente, no he hecho mucho tejido estático de IL, en su mayoría generación dinámica de IL para crear interceptores de AOP y, al hacerlo, lo he estado usando principalmente para envolver e interceptar resuelve de la inversión de los contenedores de control.

El AOP puede mejorar el manejo de excepciones, mejorar el rastreo y mejorar la interceptación de transacciones.

NHibernate, por ejemplo, tiene una especie de AOP, a pesar de que es estático en tiempo de compilación en términos de manejadores de eventos simples; pero para ciertos eventos en el motor puede adjuntar interceptores (también conocidos como aspectos, los eventos son los cortes de puntos, etc.) - Utilizo esto para inyectar, usando entidades comerciales de IoC en mis objetos de dominio.

Los potentes marcos AOP le permiten generalizar y aún más poderosos le permiten generalizar sin gastos generales en tiempo de ejecución; en principio, usted tiene algunas formas diferentes de hacerlo :

(0) (en realidad no) AOP pre-procesador de plantillas AOP en C ++, ifdefs, etc.

  1. Reflexión "AOP"
  2. La generación de IL en tiempo de ejecución a través de Reflection.Emit requiere una gran confianza. Esta es la ruta que ha tomado DynamicProxy2 en el proyecto Castle. ¡DynamicProxy2 es bastante agradable y se ha trabajado mucho! Además, afaik PatternsAndPractices Policy Framework utiliza este enfoque también, con muchos XML, aunque con su propio generador. NHibernate tiene una dependencia de DynProx2.
  3. Para la compilación de IL + Assembly.Load (...) en tiempo de ejecución mediante System.CodeDom.Compiler, luego de cargar los archivos adjuntos creados, se requiere una gran confianza. También es posible compilar con cualquier otro compilador como Boo.Compiler, ya que crea "ensambles de funciones globales" que se pueden llamar de forma "guionizada", pero ahora nos estamos alejando un poco del AOP.
  4. API de Profiler (no me preguntes sobre ellos)
  5. Confiando en el marco de tiempo de ejecución: extendiendo MarshalByRef / ContextBoundObject vea el enlace y usando la infraestructura remota en .Net para hacer AOP, que es bastante complejo e introduce dependencias que podría no desear.
  6. El entrelazado IL-weaving post-compilación, PostSharp y Mono.Cecil tiene un equivalente de Reflection.Emit, pero este no tiene errores para llamadas a métodos virtuales en subclases concretas (si no recuerdo mal) como Reflection.Emit y con mucho gusto inspeccionará su código es similar a Assembly.ReflectionOnlyLoad y también le permitirá generar operaciones IL en ese código. Este es un buen candidato si está buscando un enfoque de bajo nivel; no requiere tanta confianza
  7. Agregar puntos de extensión en su código administrado para devoluciones de llamadas no administradas a C / C ++ a través de p / invoke, pero esto requiere algo de reflexión ya que las excepciones no cruzan m / um los límites de memoria felizmente (más bien, arruinará su aplicación), y salvo está utilizando VC ++ / C # en Windows con el marco de excepciones gestionado, esto podría fallar bastante. Puede pasar la devolución de llamada a C yp / invocar en C desde C # y probablemente pasar devoluciones de C a C # y siempre que defina al delegado en C #. Los puntos de extensión probablemente tendrían que hacerse a través de un IL-weaver estático o dinámico + puntos de corte.

Usos en transacciones Eche un vistazo a Castle.Facilities.AutomaticTransactionManagement.TransactionFacility para obtener una forma agradable de manejar transacciones utilizando AOP y las capacidades de interceptación de DynamicProxy2. La función de transacción integrada con System.Transcations y System.EnterpriseServices está utilizando el coordinador de transacciones distribuidas (componente COM) para gestionar transacciones. Además, hay múltiples ejemplos de p / invoke en el kernel para encargarse de los componentes TxF y TxR de Vista-kernel (también conocido como Server 2008) que le permiten usar transacciones en NTFS y en el registro, asegurándose así de que CRUD do es ACID, que también se integra muy bien con System.Transactions para crear transacciones anidadas.

Usos en la verificación invariante También puede usarlos para el diseño por contrato, agregando algunos atributos a sus parámetros.

public void PerformOperation([NotNull, NotEmpty] string value) { // use string [NotNull] return new string('' '', 5); // can return with attributes as well }

El problema con esto en este momento es la sobrecarga de adjuntar este metadato y verificarlo en tiempo de ejecución. Sin embargo, puede especificar que el aspecto de comprobación de restricciones solo se aplique al compilar con DEBUG y luego con este metadato, lo que no provocaría un gran deterioro en el rendimiento.

Si está buscando obtener pruebas axiomáticas, eche un vistazo a Sing # / Spec #, ya que eso es más formal y el trabajo lo realiza el compilador.

Cosas a tener en cuenta El punto más importante a tener en cuenta es que si una preocupación, es decir, algún fragmento de código que se ejecuta antes o después de su método está alterando el flujo de control, posiblemente devolviendo un tipo inesperado, volviendo demasiado pronto o en general no se comporta de acuerdo con el método que usted estaba llamando, puede obtener errores que son difíciles de depurar.

Además, tenga cuidado con el lanzamiento de excepciones de los atributos, porque nunca se sabe cuándo o de qué ensamblaje, reflejo ocurre; la reflexión sobre tu atributo puede no suceder cuando lo esperas. Esto me sucedió a mí mismo cuando adjuntaba tipos de atributos y los revisaba cuidadosamente.

También tenga cuidado con el hecho de que está abriendo un posible vector de ataque al agregar "cortes de puntos" globales que, si alguien tiene acceso, pueden usarse para redirigir grandes porciones de su sistema.

Otros marcos Si está interesado en aprender más sobre AOP en general, le sugiero que consulte las presentaciones de Rickard Öberg en Qi4J , es un muy buen marco en Java para AOP (java tiene una semántica heredada de objetos ligeramente diferente, lo que hace un poco tricker a usar en C # / F # / Nermle / Boo lo que sea.

AOP + AddIns Otra posibilidad interesante en el uso de la programación orientada a aspectos con ensamblados generados en tiempo de ejecución como los crea dynamicproxy2, es que también puede usarlos para envolver objetos que cruzan los límites de la aplicación, simplificando así la creación de un add-in-pipeline. Esperaba secretamente que Microsoft usara esto cuando crearon AddIn-framework para 3.5, pero decidieron usar el modo estático de código genético desafortunadamente, lo que generó una sobrecarga bastante grande en la creación de complementos para el desarrollador. El problema es que un tipo cargado para "más que reflexión" en un AppDomain no se puede volver a descargar a menos que el AppDomain completo esté descargado, por lo que necesita 1) reflexionar sobre el complemento sin cargarlo para ver de qué es capaz a menos que permites que se escriban o generen muchos metadatos manuales (y que creas en eso) y 2) algún objeto que sujete el mango de tu objeto para que no esté codificado y no sepas el tipo (de ahí el ensamblaje IContract) y AddInHandle-class) - esto probablemente podría hacerse de una manera agradable con un proxy / AOP dinámico.

Uso de AOP para recolección de basura global ... en un sistema distribuido que se ejecuta en linux / windows en la infraestructura de lenguaje común. El documento fue un poco difícil de descargar, así que lo cargué en mi servidor para saber dónde está.

Publicar Scriptum (Si está utilizando un lenguaje no estándar en el CLR y no en el DLR, IL-weaving podría crear código que no sea compatible con los estándares. Especialmente interesante para F #, creo, porque el uso de un código no estándar es muy bueno beneficio del lenguaje (dicen las tuplas): puede marcar su ensamblaje con [assembly: CLSCompliant] si desea obtener advertencias en tiempo de compilación de esto.)