Попытка избежать жесткой связи параметров приложения

Question

Мое веб-приложение имеет метод, который анализирует параметры URL, как это.

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

В одном из отделов нашей компании есть список URL-адресов с параметрами для этого приложения, которые трудно изменить по неизвестным мне причинам. Они могут использовать URL-адрес, как это. .../default.aspx?Service=Wells&Layer=ActiveWells&Query=XYZ IN ('1234567890...')

В последнее время что-то изменилось, похоже на следующее. Название слоя "ActiveWells" изменено на "Участки участия поверхности". Название слоя "BoreStick" изменено на "WellBores". Итак, заданные параметры URL этого отдела больше не работают.

Мой менеджер сказал мне, чтобы добавить код, который изменит любые экземпляры "ActiveWells" на что-то вроде "поверхности участия поверхности". Затем менеджер сказал, что позже, когда отдел с параметрами URL изменил их все на новые имена, мы могли удалить этот код.

Я не знаю точно, что такое "жесткая связь"; но я знаю, что это плохо, и это звучит как пример этого. Мне также кажется плохой идеей добавлять код с намерением временно его сохранить и удалить позже, потому что этот код может никогда не удаляться и не окаменеть.

Но я следовал своим заказам и добавил код, подобный этому:

layerName = NameConverter.LayerNameChange(layerName);

В статическом методе LayerNameChange есть оператор switch.

Спустя месяцы или годы, кто бы ни был разработчиком, ответственным за это приложение, он должен знать, что он может прийти и удалить это, когда другой отдел завершит изменение всех предустановленных параметров URL.

Я полагаю, что другой сценарий, похожий на этот, был бы, если бы приложение на основе консоли или Windows имело параметры, которые оно ожидало для

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

Есть ли лучший способ сделать это?

---

Редактировать:

Что если вместо того, что я сказал выше, я сделал что-то вроде этого псевдокода ниже.

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

Вызывающий метод будет иметь вид,

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

Зачем методу разбора знать о существовании класса NameConverter?
Это то, что я спросил себя.
В конце концов, это не входит в обязанности парсера параметров URL, как я это вижу.

Я не знаю, думаю ли я об этом. Я новичок в этом уровне восприятия развития. Я понимаю, что на этот вопрос уже дан ответ, но любые дальнейшие комментарии по этой моей новой идее будут с благодарностью.

Answer 1

Это не проблема связи. Передача параметров по имени функции (даже веб-службе) не представляет особой проблемы.

Одной из проблем, которую необходимо решить, прежде чем вы зайдете слишком далеко, является проблема безопасности SQL-инъекций, которая просто... сидит там. Последний параметр в вашем списке является частью оператора SQL, я полагаю. Что происходит, когда кто-то создает фрагмент SQL-оператора, который наносит ущерб вашему сайту? Исследование "SQL-инъекция".

Вы правильно сделали, добавив шим NameConverter. Он выполняет перевод имен именно так, как вы должны, и предоставляет локализованный, изолированный метод для переназначения имен. Предположим, что другой отдел хочет продержаться вечно? Ваш код останется таким навсегда. Тем не менее, я бы предложил вам использовать более общую функцию карты, используя карту. Таким образом, вы получите более четкое разделение между данными и контролем.

Что может сделать ваш коллега в будущем? Ну, я надеюсь, у вас проблемы с системой продажи билетов, например, с Bugzilla или Jira. Просто подайте заявку на неопределенный будущий выпуск, который описывает прокладку NameConverter и как ее изменить. При хорошей дисциплине продажи билетов люди будут знакомы со всеми выдающимися билетами и могут вспомнить их при необходимости.