2017-08-17 1 views
0

Nous essayons d'exclure certains contrôleurs de notre code de production (nous exposons certains points de terminaison pour la manipulation API requis par nos tests d'interface utilisateur intégrée)Hors un contrôleur de code de production

Jetez un oeil à l'extrait suivant, pouvez-vous voir quelque chose de fondamentalement faux en suivant cette approche?

[AttributeUsage(AttributeTargets.Class, AllowMultiple = true, Inherited = true)] 
public class NonProductionAttribute : ApiExplorerSettingsAttribute, IActionFilter 
{ 
    public NonProductionAttribute() 
    { 
     IgnoreApi = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") == EnvironmentName.Production; 
    } 

    public void OnActionExecuted(ActionExecutedContext context) { } 

    public void OnActionExecuting(ActionExecutingContext context) 
    { 
     if (IgnoreApi) 
     { 
      context.Result = new NotFoundResult(); 
     } 
    } 
} 

Donc, fondamentalement, nous décorons simplement le contrôleur « offensant » avec l'attribut non-production, je suis héritant de ApiExplorerSettingsAttribute à exclure le contrôleur de la documentation générée.

Une préoccupation pourrait être l'utilisation de la variable d'environnement, peut-être en quelque sorte obtenir de IHostingEnvironment?

Ou suggérez-vous une alternative complètement différente (pour exclure des contrôleurs qui est)?

+2

Vous pouvez placer la variable d'environnement dans le fichier web.config, puis transformer la configuration pour chaque environnement. Je l'ai déjà fait pour un grand effet –

+0

Je pense que la partie variable d'environnement est très bien, sauf que vous pouvez l'utiliser en utilisant [config] (https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration # using-options-and-configuration-objects), seul le négatif qui vient à l'esprit est que vous aurez toutes ces routes non prod dans votre table de routage. Il se sent aussi un peu risqué, il y a un risque si cela se fait mal les choses pourraient fuir à prod. Vous pourriez regarder un processus de temps de construction pour faire la même chose. – Matt

+0

@Matt ma conception initiale impliqué le processus de construction seulement y compris ce qui est nécessaire – cstruter

Répondre

1

Déplacez tous les contrôleurs MVCC "TestOnly" et/ou les contrôleurs ApiController dans leur propre zone. Cela vous aide à identifier le Test-Only-Code beaucoup plus rapidement.

Dans votre AreaRegistration, n'enregistrez simplement aucune route en fonction du serveur/de l'environnement.

Si vous ne spécifiez pas le routage, asp.net renverra un 404 pour vous.

Vous pouvez même aller aussi loin, déplacer tout votre code de test dans son propre assemblage et l'inclure (si nécessaire) et ne même pas le construire/déployer sur prod. https://blog.longle.io/2012/03/29/building-a-composite-mvc3-application-with-pluggable-areas/

+0

J'ai essayé l'approche des zones (noyau .net), mais eu des problèmes pour l'acheminement correctement sur mon mac ... (fonctionne bien sur mes projets plus anciens) Peut-être que je faut-il faire une nouvelle tentative? Probablement juste raté quelque chose petit – cstruter

+1

Ahh succès: D, je pense que je vais suivre cette approche – cstruter