2009-02-18 9 views
18

Soy un recién llegado a la idea de la 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:Ayuda e información sobre la programación orientada a aspectos

  • ¿Debo 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 apoyar una interfaz fluida (me odia configuración XML) :)
+0

¿Qué significa un fluido? interfaz (API?) tiene que ver con la configuración XML? –

+0

Una interfaz fluida puede reemplazar la configuración xml. ver fluent-nhibernate vs nhiberate. tener la interfaz fluida significa que se puede refactorizar, por ejemplo. –

+0

[Programación Orientada a Aspectos] (http://izlooite.blogspot.com/2010/06/aspect-oriented-programming.html#comment-form) –

Respuesta

23

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.

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

NHibernate por ejemplo tiene un tipo de AOP, aunque está estático en tiempo de compilación en términos de controladores 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.

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

(0). (No realmente) "pre-procesador" plantillas AOP aka en C++, etc IFDEFs

  1. Reflection "AOP"
  2. IL-generación en tiempo de ejecución a través de Reflection.Emit, requiere alta 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 puede llamar de forma "guionizada", pero ahora nos estamos alejando un poco del AOP.
  4. API Profiler (no me pregunte por ellos)
  5. Basándose en el marco de tiempo de ejecución: extender MarshalByRef/ContextBoundObject see link y utilizando la comunicación remota de infraestructura en .Net hacer AOP, que es bastante complejo e introducir dependencias que podrían no quieren.
  6. Post-compilación estática IL-tejer, 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 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. Agregando puntos de extensión en su código administrado para callbacks no administrados 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 la memoria felizmente (más bien, arruinarán su aplicación) , y a menos que esté usando VC++/C# en Windows con el marco de excepción administrado, 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 las transacciones Tenga una mirada en Castle.Facilities.AutomaticTransactionManagement.TransactionFacility para una buena manera de manejar las transacciones que utilizan 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 ocuparse de TxF and TxR components of the Vista-kernel (aka Server 2008) que le permiten usar transacciones en NTFS y en el registro, asegurándose de que CRUD lo haga es ACID, que también se integra muy bien con System.Transactions para creando 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 este en este momento es la sobrecarga de fijación de este meta-datos y la comprobación 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# en su lugar, 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, alguna pieza de código que se ejecuta antes o después de su método está alterando el flujo de control, posiblemente devolver un tipo inesperado Si regresa demasiado temprano o, en general, no se comporta de acuerdo con el método que estaba llamando, es posible que obtenga 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 se produce la reflexión; la reflexión sobre tu atributo puede no suceder cuando lo esperas. Esto me sucedió a mí mismo cuando añadí tipos de atributos y los revisé cuidadosamente.

Tenga también en cuenta que está abriendo un posible vector de ataque al agregar "cortes de puntos" globales que, si alguien tiene acceso, pueden utilizarse para redirigir grandes partes de su sistema.

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

AOP + AddIns Otra posibilidad interesante en el uso de la programación orientada a aspectos con los conjuntos generados en tiempo de ejecución, como los que crea dynamicproxy2, es que se también puede usarlos para envolver objetos que cruzan los límites de la aplicación, Reby simplifica la creación de un add-in-pipeline. Esperaba en secreto que Microsoft lo usara 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 sea GCed y no sepas el tipo (de ahí el ensamblado 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 por lo que I uploaded it to my server así sé dónde está.

Post Data (Si está utilizando un idioma no estándar en el CLR y no el DLR IL-tejer podría crear no-estándares de código compatible. Especialmente interesante para F #, creo, porque el uso una lote de código no estándar para gran beneficio del idioma (dicen las tuplas): puede marcar su ensamblaje con [assembly: CLSCompliant] si desea obtener advertencias en tiempo de compilación de esto.)

+0

wow! gran explicación lo que esperaba y más. ¡Gracias! –

+0

comentarios impresionantes. Muy agradable. – CmdrTallen

1

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.

0

No creo que sea 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.

1

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

2

No puedo hablar por 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 design by contract. 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 cortar & pegarlo en todos los métodos.

Durante las pruebas, a menudo es útil saber qué está sucediendo 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 tenga 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.

Cuestiones relacionadas