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

Question

Как вы управляете большими 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&lh_bin=1&_nkw=nikon&_catref=1&lh_bin=1&_nkw=nikon&_catref=1&lh_bin=1&_nkw=nikon&_liuction & _mprrngcbx = 1 & _SC = 1 & _SOP = 15 & _stpos = & _ trksid = p3286.c0.m283 & gbr = 1

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

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

 $readableName = $_GET['_f'];

Но затем вы заканчиваете множеством VAR, и, вероятно, вам нужны все в функции, поэтому вместо нового VAR для каждого параметра запроса мы можем использовать массив:

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

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

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

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

Внутри Vo? Helper URL -класс? Просмотреть модельный базовый класс?

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

Answer 1

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

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

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

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

Answer 2

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

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

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