Essayer d'éviter le couplage étroit des paramètres d'application

Question

Mon application Web dispose d'une méthode qui analyse les paramètres d'URL de cette manière.

... 
layerName = HtmlPage.Document.QueryString["Layer"] . . . ; 
... 

un des départements de notre entreprise a une liste d'URL avec des paramètres pour cette application qui sont difficiles à modifier, pour des raisons qui me sont inconnues. Ils pourraient utiliser une URL comme celle-ci. .../default.aspx? Service = Wells & couche = ActiveWells & query = XYZ IN ('1234567890 ...)

Récemment, somethings changé semblable à ce qui suit. Le nom de la couche "ActiveWells" a été remplacé par "Surface Participation Wells". Le nom de la couche "BoreStick" a été remplacé par "WellBores". Ainsi, les paramètres d'URL prédéfinis de ce département ne fonctionnent plus.

Mon responsable m'a dit d'ajouter du code qui remplacerait toutes les instances de "ActiveWells" par quelque chose comme "Surface Participation Wells". Le gestionnaire a ensuite déclaré que plus tard, lorsque le département avec les paramètres d'URL les avait tous changés pour les nouveaux noms, nous pourrions supprimer ce code.

Je ne sais pas exactement ce qu'est le "couplage serré"; mais je sais que c'est mauvais et cela ressemble à un exemple. Cela me semble aussi une mauvaise idée d'ajouter du code avec l'intention de le conserver temporairement et de le supprimer plus tard parce que ce code pourrait ne jamais être retiré et se fossiliser.

Mais j'ai suivi mes ordres et j'ajouté le code comme ceci:

layerName = NameConverter.LayerNameChange(layerName); 

Il y a une instruction switch dans la méthode LayerNameChange statique.

Des mois ou des années à partir de maintenant, quel que soit le développeur responsable de cette application est censé savoir pour entrer et supprimer ce lorsque ce autre ministère a terminé de modifier tous les paramètres d'URL prédéfinis.

Je suppose une autre scenerio semblable à ceci serait si une console ou une application basée sur Windows ont des paramètres qu'elle prévoyait pour la

Main(string[] args){...} 

Y at-il une meilleure façon de faire cela?

---

Edit:

Et si au lieu de ce que je l'ai dit plus haut, je l'ai fait quelque chose comme ça pseudocode ci-dessous.

private void MethodToParseURL_Parameters(Func<string, string> nameReplace) 
{ 
    . . . 
    layerName = nameReplace(layerName); 
    . . . 
} 

La méthode d'appel aurait une sorte de,

MethodToParseURL_Parameters(new Func<string, string>(NameConverter.LayerNameChange)); 

Pourquoi la méthode d'analyse syntaxique besoin de connaître l'existence de la classe NameConverter?
C'est ce que je me suis demandé.
Après tout, cela ne fait pas partie de la responsabilité de l'analyse des paramètres d'URL comme je le vois.

Je ne sais pas si je suis en train de trop réfléchir. Je suis nouveau à ce niveau de perception du développement. Je comprends que la question a déjà reçu une réponse, mais tout autre commentaire sur cette nouvelle idée serait grandement apprécié.

Answer 1

Ceci n'est pas un problème de couplage. Passer des paramètres par nom à une fonction (même un service Web) n'est pas particulièrement un problème.

Un problème qui doit être résolu avant d'aller plus loin est le problème de sécurité de l'injection SQL qui est juste ... assis là. Le dernier paramètre de votre liste fait partie d'une instruction SQL, je présume. Que se passe-t-il lorsque quelqu'un crée un fragment d'une instruction SQL qui endommage votre site? Recherche "Injection SQL".

Vous avez fait la bonne chose, en ajoutant le shim NameConverter. Il fait une traduction des noms juste comme vous êtes censé, et fournit une méthode localisée et isolée pour remapper les noms. Supposons qu'un autre département veuille tenir pour toujours? Votre code restera ainsi pour toujours. Cependant, je suggère que vous allez avec une fonction de carte plus générale, en utilisant une carte. De cette façon, vous avez une séparation plus nette entre les données et le contrôle.

En ce qui concerne ce que votre collègue peut faire dans le futur? Eh bien, j'espère que vous avez un système de billetterie, comme Bugzilla ou Jira. Il suffit de déposer un ticket pour une version future non définie qui décrit le module d'interface NameConverter et comment le modifier. Avec une bonne discipline de billetterie, les gens seront au courant de tous les billets en circulation et peuvent le rappeler en cas de besoin.