Aspect para C# (.Net) y sus características

Question

me gustaría pedir 3 información aquí:

1. No es ninguna solución integrada para Aspect Oriented Programación (AOP) en C# (.Net) de Microsoft ¿es correcto? ¿Hay alguna solución de este tipo en desarrollo o planificada?

2. ¿Qué soluciones hay que permiten la Programación Orientada a Aspectos (AOP) para ser utilizada en C# (.Net)? ¿Cuáles son las ventajas/desventajas de ? No he encontrado ninguna lista exhaustiva que contenga todas las opciones disponibles y cierta información para que yo decida cuál es la que debo usar. El más cercano es this list.

3. ¿Cuál es (en su opinión) la mejor AOP solución para C# (neto). considerando siguiente criterios:

   1. que schould funcionan de manera similar a AspectJ y tiene una sintaxis similar
   2. simplicidad de uso: no se necesita configuración XML; solo escriba algunas clases regulares, algunas clases de aspecto y compile para enlazarlo todo, luego ejecútelo.
   3. debe incluir todas las funciones de AspectJ. Soporte para genéricos.
   4. solución debe ser estable, ampliamente utilizado y mantenido.
   5. debe ofrecer el tejido de binarios (por lo que podría usarse) o el código fuente de C#.
   6. Herramienta de GUI para visualizar (o incluso mejor - complementos para VS) es una ventaja.

creo que si algo fullfils la mayor parte de los criterios de 3. entonces es un candidato para una solución utilizada generaly. Y no puedo encontrar nada si algunas de las soluciones existentes se ajustan a mis necesidades.

Answer 1

Como señala Adam Rackis, Post # es el camino a seguir, está lo más cerca que podrá llegar a AspectJ en la plataforma .NET.

Las diferencias principales son, obviamente, que AspecJ tiene soporte de idiomas para los aspectos, mientras que Post # es un tejedor de compilación posterior para los ensamblados de .NET. (por lo tanto sin la integración de lenguajes)

Sin embargo, Anuncio # puede utilizar unirse a puntos tales como el acceso al terreno, tratar bloques catch, ambas llamadas y funciones (es decir, la persona que llama y el destinatario de la llamada)

1. Sin ni siquiera estrecha, AspectJ es un lenguaje, Anuncio # puede utilizar puntos de corte personalizados, pero el más común es el uso de atributos para decorar los métodos que se pointcutted (eh..grammar?)

2. cheque

3. todo pero lang apoyo uage

4. cheque

5. cheque - es un puesto de compilar tejedora

6. limitada, el tejedor generará información IntelliSense y mostrar qué métodos se han visto afectados

Si desea un lenguaje .NET que admita aspectos, consulte http://aspectsharpcomp.sourceforge.net/samples.htm

Rega rding diferentes enfoques, hay algunos:

1. Publicar el tejido, esto es lo que hace Post #. Simplemente destruye el ensamblado .NET e inyecta el código de aspecto.

2. Real Proxy/MarshallByRefObject. Basado en infraestructura remota. Requiere que sus clases hereden de una clase base. Rendimiento extremadamente malo y sin "auto interceptación"

3. Dynamic Proxy. Esto es lo que usaba mi antigua biblioteca NAspect. utiliza una fábrica para crear una subclase del tipo en el que desea aplicar aspectos. La subclase agregará código de mezcla utilizando interfaces y anulará los métodos virtuales e inyectará código de interceptor.

4. Tejido de código fuente. Como su nombre lo indica, transforma su código fuente antes de la compilación.

[editar] Se me olvidó añadir ésta a la lista:

5. proxies de interfaz similares a proxy dinámico, pero en lugar de aplicar el código de intercepción a una subclase, el código de interceptación se agrega a un proxy de interfaz generado en tiempo de ejecución. Es decir, obtiene un objeto que implementa una interfaz determinada, este objeto luego delega cada llamada a cualquiera de los métodos de interfaz primero al código de interceptación AOP y luego delega la llamada al objeto real. Es decir, tiene dos objetos en juego aquí, el proxy y el sujeto (su objeto real).

Client -> Interface Proxy -> AOP interception -> Target/Subject

Esto es lo que la primavera hace que yo sepa.

1) y 3) son los más comunes. Ambos tienen pros y contras:

mensaje de compilación:

Pros:

• puede señalar cortar casi todo, estática, cerrados y privados
• objetos todavía se pueden crear utilizando "nueva "

Contras:

• No se pueden aplicar aspectos según el contexto, es decir, si un tipo se ve afectado, se verá afectado por la aplicación completa.

• El corte puntual de construcciones privadas, estáticas y selladas puede generar confusión ya que rompe las reglas fundamentales de OO.

dinámico Proxy:

Pros:

• contextuales, uno típico puede tener diferentes aspectos aplican en función del contexto.

• Fácil de usar, sin configuración ni pasos de compilación.

Contras:

• pointcuts Limited, única interfaz miembros y los miembros virtuales pueden ser interceptados

• debe utilizar la fábrica para crear objetos

Answer 2

1 - correcta

2 - PostSharp es una excelente biblioteca AOP para C#

3 - No sé cómo funciona AspectJ, pero con PostSharp sólo tiene que definir sus aspectos como atributos, y luego decora tus métodos con dichos atributos.

He aquí un ejemplo de un aspecto que envuelve una llamada al método con un intento de captura, y los registros de las excepciones que se tiran:

[Serializable] 
public class ErrorAspectAttribute : OnMethodBoundaryAspect { 
    private bool Notify; 

    public ErrorAspectAttribute(bool notifyUser = true) { 
     this.Notify = notifyUser; 
    } 

    public override void OnException(MethodExecutionEventArgs args) { 
     ErrorLoggerUtil.LogException(args.Exception);   

     if (Notify) 
      MessageBox.Show("An error has occurred. Please save blah blah blah", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error); 

     args.FlowBehavior = FlowBehavior.Return; 
    } 
} 

Así, punto por punto

1 - no sé

2 - comprobar

3 - no sé 4 - comprobar

5 - cheque (casi seguro)

6 - no - no sé como se puede utilizar una interfaz gráfica para la visualización de aspectos como esto

Answer 3

El problema es que usted está comparando diferentes idiomas y tratando de forzar clavijas cuadradas en agujeros redondos

Para Java AspectJ satisface una necesidad debido a los límites en el idioma, pero .NET no necesariamente tiene estas limitaciones, ya que la JVM no lo hace, pero Java sí.

Por ejemplo, puede usar IronPython o IronRuby (además de otros) para escribir ensamblajes que son muy dinámicos, de modo que puede escribir un DSL (lenguaje específico del dominio) que permitirá a un usuario agregar un código que no es XML, pero cambiará la forma en que funciona el programa.

Puede usar métodos de extensión en C# para cambiar el comportamiento intercambiando ensamblados, de modo que tenga un ensamblado que tenga extensiones que se registren en un archivo, luego cambie ese ensamblaje por otro con el mismo espacio de nombres que enviará el datos a un servicio web, o hacer un noop.

Pero hay limitaciones que pueden ser difíciles de superar, como ser capaz de usar un aspecto para hacer algo en cada función llamada, como usar cflow (http://www.eclipse.org/aspectj/doc/released/progguide/semantics-pointcuts.html), pero eso puede deberse a que no lo he hecho. Pensé lo suficiente acerca de cómo hacerlo.

Mi objetivo no es dar una explicación completa de cómo .NET no necesita AspectJ, sino mostrar que hay formas de obtener el comportamiento que puede esperar sin utilizar AOP.

Para las aplicaciones que se ejecutan en la JVM, puede usar Groovy, Clojure, JRuby y Scala, por ejemplo, para evitar las limitaciones de Java.

ACTUALIZACIÓN:

Tenía la esperanza de mantener mi respuesta más corto, pero una cierta comprensión de AOP puede ser útil añadir contexto a mi respuesta.

La Programación Orientada a Aspectos (AOP) es un paradigma de programación diferente, para una funcionalidad que abarca varias clases, como el registro. El registro es una situación común, donde es posible que desee registrar todas las consultas SQL que se utilizan, por lo que, en lugar de copiar el código de un lugar a otro, lo coloca en un lugar y se coloca en todos los lugares que especifique. para cambiar el destino del registro, lo cambia en un solo lugar.

Pero con AspectJ hay más opciones. Por ejemplo, vende un programa que almacena contraseñas. La empresa A usa IDEA, la compañía B usa AES. Para adaptarse, cambie el código que se usa en tiempo de ejecución para no arriesgarse a recompilar el código e introducir nuevos errores, y se cambia, de modo que cada vez que alguien llame al getPassword(), se use el nuevo código para descifrarlo.

También puede agregar funcionalidad a una clase existente, así que pondría métodos en las interfaces para que todo lo que utilizara esa interfaz ahora tuviera acceso a las funciones, de modo que los métodos ahora fueran concretos, en la interfaz.

Pero, al usar otros lenguajes que están en .NET y JVM, puede hacer todo esto, con la misma modularidad, eligiendo cuidadosamente qué idioma usar. Por ejemplo, en Java puede acceder a clases escritas en Groovy o Scala, por lo que puede obtener más flexibilidad con estos idiomas y aún tener la aplicación principal en Java.

En C# puede usar F #, IronPython o IronRuby, por ejemplo, para obtener esta funcionalidad o, en algunos casos, puede usar C#.

Por lo tanto, la necesidad de una programación orientada a aspectos se ve disminuida debido a estos lenguajes funcionales dinámicos o fuertemente tipados disponibles en estas máquinas virtuales, pero usted cambia la complejidad de trabajar con aspectos con una solución multilingüe.

Para más información sobre AOP, IBM tenía algunos artículos increíbles sobre su uso, con su AOP @ Work serie: http://www.ibm.com/developerworks/views/java/libraryview.jsp?search_by=AOP@work:

Para algunas reflexiones sobre AOP en .NET se puede leer Código mangling AOP vs. Proxy Runtime AOP , http://rogeralsing.com/2008/01/08/code-mangling-aop-vs-runtime-proxy-aop/