Как управлять URL-адресами с большим количеством параметров запроса? - PullRequest
2 голосов
/ 06 сентября 2011

Как вы управляете большими URL-адресами (с большим количеством параметров запроса) в своем приложении?

Например, посмотрите эту ссылку на ebay (не нажимайте на ссылку, это просто пример большого URL-адреса)):

http://www.ebay.com/sch/Cameras-Photo-/625/i.html?LH_ItemCondition=1&LH_Price=15..500%40c&rt=nc&LH_Auction=1&LH_BIN=1&_nkw=nikon&_catref=1&_clu=2&_fcid=12&_fln=1&_localstpos=&_mPrRngCbx=1&_sc=1&_sop=15&_stpos=&_trksid=p3286.c0.m283&gbr=1

Вы можете увидеть множество параметров, многие из которых со странными и короткими именами, такими как "_f", "_sc" и т. Д.

ВыВы не можете использовать эти параметры в своем приложении, вам нужно преобразовать их во что-то более «читабельное»:

 $readableName = $_GET['_f'];

, но тогда вы получите множество переменных, и, вероятно, вам понадобятся все из них в функции.Таким образом, вместо нового var для каждого параметра запроса мы можем использовать массив:

$readableParams['readableName'] = $_GET['_f']; 

Но затем мы заканчиваем большим массивом с произвольной структурой, поэтому я думаю, что лучшая идея - это иметьVO (DTO) для этих параметров, что-то вроде:

$filterVo = new FilterVo();
$filterVo->readableName = $_GET['_f'];

Это нормально, но куда мы поместим этот код?Я имею в виду, где лучше всего выполнить преобразование из «редких параметров запроса» в «очистить объекты значения»?
Поскольку нам также необходим обратный процесс, мы можем создать VO с данными, а затем сгенерировать URLс правильными параметрами запроса от этого VO.

Внутри VO?Вспомогательный класс URL?Просмотреть базовый класс модели?

Как вы управляете этими URL-адресами с большим количеством параметров?

Ответы [ 2 ]

1 голос
/ 06 сентября 2011

Интересно, что вы назвали вводные имена загадочными. Я собираюсь ответить в общем смысле (не только на специфику PHP) на то, что я видел в своих проектах, которые я считаю относящимися к этой теме. Общий подход:

  • Переменные формы обычно сопоставляются с объектом. Это VO в PHP или Beans в Java. Это будет наиболее читаемая форма трансформации (на мой взгляд), поскольку она дает контекст HTML-формам, которые конвертируются
  • Во многих случаях я видел некоторый класс Form Utilities Helper, который будет обрабатывать преобразование в и из. Тем не менее, это не конкретное жестко закодированное преобразование, большая часть преобразования является очень структурированной и общей. Например, он принимает все методы getters / setters и использует его как имя формы. Например, у меня может быть getUsername() в моем объекте, тогда Утилиты Формы переведут его, например, в <input name="username"/>.
  • При желании вы также можете переопределить сопоставление по умолчанию с помощью переопределения сопоставления. Это может быть в форме:
    • Файл конфигурации, например, XML-файл, который сопоставляет переменную экземпляра с переменной формы. В приведенном выше примере такое сопоставление может быть для сопоставления переменной экземпляра имени пользователя с более загадочной переменной формы с именем u
    • Функция языка, такая как аннотация в Java или атрибут в C #. Функция языка позволила бы сделать сопоставление без файла конфигурации, но встроенным в сам исходный код объекта
  • Я видел проекты, которые имели бы базовый класс для VO / Bean с fromForm(input) и toForm(), использующими утилиты форм, упомянутые выше. Это обеспечивает удобство для разработчиков, поэтому им не приходится иметь дело с утилитами форм, а просто вызывать toForm() и fromForm(input) из своего объекта для обработки преобразования

Теперь, учитывая шаблон выше, для загадочных полей формы я обычно вижу:

  • Создание объекта VO для представления полей
  • Создание конфигурации сопоставления для сопоставления загадочного поля с фактической переменной экземпляра с логическим именем
  • Либо используйте вспомогательный класс Form Utilities напрямую, либо, если утилиты Form Utilities используются в базовом классе, используйте вспомогательные методы toForm() и fromForm(input)
0 голосов
/ 06 сентября 2011

Большинство этих параметров генерируются автоматически. Я видел такое поведение во многих приложениях ASP.NET. И я ненавижу .NET за такие вещи, но я не хочу начинать эту тему снова .

В большинстве случаев эти дополнительные параметры генерируются выпадающими модулями . Они работают в автоматическом режиме, выполняя некоторые вещи, которые непосредственно не отражены в приложении (часть, которую по крайней мере пишет разработчик приложения), или помогают в других задачах. Это способ поддерживать состояние между запросами.

С другой стороны, вы могли бы реализовать описанный вами механизм. В среде MVC эта задача будет выполняться контроллером. Это имеет смысл только в том случае, если передается МНОЖЕСТВО параметров GET. Вы должны стараться избегать такого рода практики с самого начала.

...