Używanie niestandardowej IHttpActionInvoker w interfejsie WebAPI do obsługi wyjątków

Question

Próbuję dodać niestandardową IHttpActionInvoker do mojej aplikacji WebAPI, aby zapobiec wielokrotnemu powtarzaniu kodu obsługi wyjątków w moich metodach działania.

Naprawdę nie wydaje się, że jest dużo o tym, jak zrobić to inaczej niż this article. Po napisaniu mojego IHttpActionInvoker zgodnie z artykułem I dodaje ten kod:

GlobalConfiguration.Configuration.Services.Remove(typeof(IHttpActionInvoker), 
GlobalConfiguration.Configuration.Services.GetActionInvoker()); 

GlobalConfiguration.Configuration.Services.Add(typeof(IHttpActionInvoker), 
new MyApiControllerActionInvoker()); 

do metody w moim pliku Global.asax. Teraz podczas wykonywania wywołania mojego interfejsu API otrzymuję następujący wyjątek podniesiony w metodzie Remove():

The service type IHttpActionInvoker is not supported 

Chyba mam dwa pytania.

1. Zważywszy tam nie widać, aby być bardzo dużo tam o pisaniu własnych klas IHttpActionInvoker jest to uważane za dobre podejście do rozwiązywania obsługę wyjątków w aplikacjach WebAPI?

2. Czy ktoś wie, dlaczego uzyskałbym taki wyjątek podczas wykonywania metody Remove() i jak najlepiej rozwiązać ten konkretny problem?

Answer 1

Wystąpił ten sam błąd, który opisałeś przy próbie usunięcia usługi.

Odkryłem, że nie muszę usuwać czegokolwiek z globalnej konfiguracji, ponieważ pojawia się, jeśli zarejestrowałeś interfejs w swoim kontenerze, najpierw to rozwiąże.

Na przykład, używam SimpleInjector iw moim global.asax mam to:

container.Register<IHttpActionInvoker , MyApiControllerActionInvoker >(); 
// Register the dependency resolver. 
GlobalConfiguration.Configuration.DependencyResolver = 
    new SimpleInjectorWebApiDependencyResolver(container); 

W czasie wykonywania jest rozwiązanie zależność MyApiControllerActionInvoker razie potrzeby.

Następnie można wykonać obsługę wyjątków w kliencie ActionInvoker, a wszelkie zależności określone w konstruktorze zostaną poprawnie połączone. Powodem, dla którego patrzyłem na ActionInvoker, było wstrzyknięcie konstruktora, ponieważ wstrzyknięcie do Atrybutu wydaje się wymagać wstrzyknięcia właściwości.

Również zamiast usuwania/wstawiania, wymiana wydaje się działać. (W Global.asax)

GlobalConfiguration.Configuration.Services.Replace(typeof(IHttpActionInvoker), new MyApiControllerActionInvoker(fooService)); 

Answer 2

Czy rozważałeś rejestrację filtra wyjątków? Oto niektóre dokumenty o tym:

http://www.asp.net/web-api/overview/web-api-routing-and-actions/exception-handling

Nie powinniśmy mieć spadek w dół do warstwy działania wywołującego jeśli wszystko, co chcesz zrobić, to obsługiwać pewne wyjątki w sposób szczególny.

Answer 3

Jak dla mnie to działa z IActionInvoker zamiast IHttpActionInvoker. Jak rozumiem, IHttpActionInvoker jest używany do połączeń async api, prawda?

public class RepControllerActionInvoker : ControllerActionInvoker 
{ 
    ILogger _log; 

    public RepControllerActionInvoker() 
     : base() 
    { 
     _log = DependencyResolver.Current.GetService<ILogger>(); 
    } 

    public override bool InvokeAction(ControllerContext controllerContext, string actionName) 
    { 
     try 
     { 
      return base.InvokeAction(controllerContext, actionName); 
     } 
     catch (Exception e) 
     { 
      _log.Error(e); 
      throw new HttpException(500, "Internal error"); 
     } 
    } 
}