2010-02-10 9 views
10

Tengo una aplicación ASP.NET 3.5 SP1 Webforms. Uso el patrón MVP (controlador de supervisión) con DI (autofac). Mis presentadores llaman a los contratos de repositorio definidos en mi Dominio (DDD) que se implementan en un proyecto de Infraestructura.Asesoramiento en AOP con C#

Los métodos de depósito que llaman los presentadores pueden funcionar, así que tengo que registrar excepciones y luego establecer un mensaje de error en la Vista.

En el pasado habría agregado otro parámetro a los constructores del presentador, guardé la referencia en un presentador base y llamé a un método de registro en mis bloques de captura. Realmente no me gusta esto, pero hace el trabajo bien.

Podría ir por la ruta de usar una fábrica para obtener la clase de registro as described here, pero me gustaría explorar AOP primero, ya que parece bastante interesante.

me han hecho la lectura en tiempo de compilación en tiempo de ejecución vs AOP, y me gustaría saber qué experiencias de la gente están con las diferentes soluciones, ventajas, desventajas, palabras de consejo, etc.

Desde el excavación que he hecho parece que hay 4 principales marcos de AOP en .NET

  • Castillo de Windsor - me han mantenido al margen de esta, en general, ya que una gran cantidad de cosas que realmente no necesita
  • Spring.net - parece que tiene una buena trayectoria pero inspira temor a través de su configuración xml (no lo hago como no fluente configuraciones)
  • PostSharp - Atributo impulsadas (me gusta esto) pero en un momento some line number issues tenido, no estoy seguro si es que todavía existen
  • la unidad - un montón de cosas que realmente no necesita

Veo another question que tiene algunas buenas respuestas, pero es de hace un año y medio. ¿Existen marcos más nuevos, "mejores", que se hayan desarrollado mientras tanto, o mejoras hechas a soluciones existentes que deberían tomarse en consideración?

Como referencia, elegí Autofac para DI porque es fluido, fácil de usar, no pudo encontrar ningún comentario negativo al respecto, y simplemente funciona.

¿Hay recomendaciones sobre qué marco AOP debería probar? Gracias por leer todo esto y por agregar cualquier pensamiento.

+1

estaría interesado en detalles de por qué desea utilizar AOP. Todavía tengo que encontrar un escenario donde fue lo suficientemente bueno para satisfacer mis necesidades. Por ejemplo, logging. Los registradores AOP pueden decirme cuándo se golpea un método específico, pero eso nunca es suficiente información. Siempre necesito usar un registrador ** dentro ** del método, así como ** alrededor de **. Me interesaría saber cómo AOP podría ayudarte. No estoy criticando a AOP: soy escéptico y estoy buscando qué escenarios del mundo real son realmente convincentes para llevar a cabo la AOP goo. –

+0

Mencioné en la pregunta su para excepciones de registro por ahora. – blu

+0

Tu punto está bien visto mirando hacia atrás. Terminé usando una fábrica con un delegado para crear el registrador que se mapeó en mi contenedor IoC. En el marco de tiempo dado no bajé por el camino de AOP, pero aún estoy interesado en ver qué tan útil puede ser. – blu

Respuesta

4

Respuesta breve, por simplicidad y facilidad de uso, realmente no puede salir mal con PostSharp.

Respuesta más larga: En mi opinión, debe elegir entre los dos marcos en función de lo que está tratando de lograr.

Si desea aspectos que deberían cambiar en función del contexto, considere Spring.NET (o cualquier marco aop que inyecte código en tiempo de ejecución en función de la configuración). Esto le permite personalizar el comportamiento de sus objetos dependiendo de lo que esté haciendo.Por ejemplo, a través de su configuración, puede usar un tipo de registro en una aplicación de consola y otro en una aplicación web. Tenga en cuenta que Spring también es un contenedor DI (y varias otras cosas); va más allá de AOP, y definitivamente vale la pena aprender a usarlo.

Por otro lado, si quieres comportamiento que debe siempre estará en efecto, independientemente del contexto, entonces PostSharp (compilar tejer tiempo) es la mejor opción. Esto es efectivamente lo mismo que si incluye el código en cada método para aplicar el aspecto.

Por lo que estás haciendo, te recomiendo que comiences con PostSharp.

+0

Gracias por la entrada, aceptando como la mejor respuesta a la pregunta. – blu

+0

599 € por desarrollador * PostSharp Ultimate – Legends

0

He estado utilizando PostSharp durante bastante tiempo y debo decir que estoy disfrutando de la facilidad de uso y la simplicidad de la implementación.

Debo añadir que, personalmente, cuando uso un framework, siempre trato de seguir con un solo marco de responsabilidad, a menos que el framework contenga muchos componentes que necesito o complementa el núcleo.

0

Para escenarios de aspecto simples, pasaría el cuerpo del método como un bloque a un método genérico que maneja el aspecto, es decir, la implementación de the «hole in the middle» design pattern.

Ejemplo:

public class Class 
{ 
    public void MethodWithoutAspect() 
    { 
     var dummy = new string('a', 10); 

     Console.WriteLine(dummy); 
    } 

    public void MethodWithAspect() 
    { 
     Aspect.LogException(() => 
     { 
      var dummy = new string('a', 10); 

      Console.WriteLine(dummy); 
     }); 
    } 
} 

public static class Aspect 
{ 
    public static void LogException(Action block) 
    { 
     try 
     { 
      block(); 
     } 
     catch (Exception e) 
     { 
      Log(e); 
      throw; 
     } 
    } 

    private static void Log(Exception e) 
    { 
     throw new NotImplementedException(); 
    } 
} 
+0

Por favor, agrega un comentario al votar abajo. –

+1

-1 esta técnica no se relaciona con AOP –

+0

El concepto de AOP es el comportamiento de inyección al código existente sin cambiar la implementación existente. En esta muestra, si decide cambiar el aspecto, debe refactorizar todo el código. –