ASP.NET MVC Укажите категорию / путь вне маршрутизации URL-адресов

У меня проблема с принятием решения о включении категории / пути в URL-маршрутизацию. Предположим, в моем образце веб-приложения есть продукты, относящиеся к некоторым категориям. Например:

Book1 Attached to -> Category1 | Category2 
Book2 Attached to -> Category1 | Category2 | Category3
Book3 Attached to -> Category2 | Category3

И определенная карта маршрутизации для продуктов:

url: "{controller}/{action}/{languageCode}/{category}/{product}"
defaults: new { controller = "Home", action = "ViewItem" }

Итак, возможная маршрутизация для Book1:

[Domain Name]/Home/ViewItem/en-US/Category1/Book1
[Domain Name]/Home/ViewItem/en-US/Category2/Book1

Возможная маршрутизация для Book2:

[Domain Name]/Home/ViewItem/en-US/Category1/Book2
[Domain Name]/Home/ViewItem/en-US/Category2/Book2
[Domain Name]/Home/ViewItem/en-US/Category3/Book2

Я хочу сохранить и узнать текущую категорию, но у меня есть один уникальный URL-адрес для каждого продукта (для отслеживания и обмена URL-адресами поисковой системы). Думаю использовать Переменная сеанса или ViewBag, даже Cookie-файлы, но у каждого из них есть свои ограничения и минусы. Например, использование файлов cookie может вызвать некоторые проблемы: если установить слишком малое время истечения срока действия, он может потерять текущий путь, когда пользователь приостанавливает работу на некоторых страницах, а если он установлен слишком долго, может привести пользователя к старому пути просмотра, даже если пользователь запросил домашнюю страницу в новом открывающемся браузере из-за существующего файла cookie (за исключением того, что у меня был некоторый опыт работы с файлами cookie, и я считаю, что это не работает точно всегда), О Сессия и ViewBag Я не знаю, лучше ли их использовать, Так может ли кто-нибудь поделиться проверенным решением или хорошей идеей? Я буду признателен за это.

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

QMaster 04.05.2018 11:23
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
2
1
230
2

Ответы 2

У вас должна быть страница mywebsite.com/product1 (каноническая версия URL). Включение всех версий URL не поможет. Скорее всего, это просто запутает Google и может привести к тому, что Google проигнорирует определенные URL-адреса.

Даже если вы укажете каноническую версию и на ваших страницах будет тег rel canonical, Google может по-прежнему рассматривать другую версию URL как каноническую.

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

Спасибо за ответ, но самое главное - как хранить и отслеживать выбранную категорию? После перенаправления URL-адреса на версию без категории я потеряю его, я ошибаюсь?

QMaster 08.05.2018 23:36

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

QMaster 09.05.2018 15:38

Я думаю, что @Mikaal заслуживает награды, но я ценю вас за внимание, я укажу на ваш ответ +1, еще раз спасибо.

QMaster 10.05.2018 22:29

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

Тогда у вас будут такие URL-адреса:

{домен} / {контроллер} / книга / идентификатор

А для представлений, связанных с «категорией» или «языковым кодом», у вас могут быть URL-адреса, например:

{домен} / {контроллер} / search? languageCode = enUS & category = 1

Это все равно будет идеально RESTful и, на мой взгляд, намного проще.

Я не хочу, чтобы URL-адрес имел форму «? Param = value & ...», вы можете просмотреть отличные веб-сайты и увидеть, что языковые коды являются частью URL-адреса, например «/ en / ...», потому что некоторый контент может существуют на одном языке и не существуют на другом, поэтому наличие кода языка в URL-адресе логично, но по категориям вы можете перейти к специальному продукту из разных категорий. Продукт уникален, но категория! Мне нужно знать категорию без URL-адреса.

QMaster 10.05.2018 17:29

Если вы хотите избежать чего-либо в URL-адресе, вы можете выполнить запрос POST вместо GET, чтобы они не отображались в URL-адресе.

Mikaal Anwar 10.05.2018 17:44

Если вы хотите отслеживать категорию, не сохраняя ее в URL-адресе, вы можете: 1) Передать ее как параметр запроса (в запросе POST или GET, в зависимости от того, хотите ли вы, чтобы он отображался в URL). 2) Передайте его с помощью ViewBag. Если вы хотите сохранить это в течение более длительного периода, вы можете добавить его в сеанс, но вам также нужно будет обновлять это каждый раз при смене категории. И, читая ваш вопрос выше, я бы посоветовал вам хранить только «categoryName / categoryId» в «Session» / «ViewBag» / «Request Parameter» вместо «Path».

Mikaal Anwar 10.05.2018 17:44

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

QMaster 10.05.2018 20:09

На основании моих знаний «Как вы сохраняете категорию на своем сервере?» не повлияет на SEO / удобство поиска ваших веб-страниц, потому что поисковые системы не зависят от внутреннего устройства вашего сервера. А с технической точки зрения, какие подходы использовать полностью зависит от вас, если вам не нужно сохранять «категорию» в течение более длительного периода, то «ViewBag» может быть хорошим и простым решением. В противном случае сеанс тоже был бы хорош.

Mikaal Anwar 10.05.2018 21:08

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

Mikaal Anwar 10.05.2018 21:08

Хорошее практическое правило согласно руководящим принципам REST - иметь один уникальный URI для каждого ресурса. Если у вас есть несколько URI, представляющих один и тот же ресурс, вы, вероятно, в конечном итоге уменьшите SEO, поскольку вместо одной часто посещаемой страницы у вас будут две чуть менее посещаемые страницы. И я думаю, что первое лучше. Кроме того, я не знаю, как это может повлиять на SEO.

Mikaal Anwar 10.05.2018 21:09

Представьте, что вы поделились URL-адресом для специального продукта, например, в Facebook, и у вас есть категория в этом URL-адресе. Через некоторое время вы удаляете эту категорию, но продукт. Теперь этот URL-адрес не будет работать, потому что категория не существует. Это простой пример, чтобы понять мой взгляд.

QMaster 10.05.2018 21:16

Ааа, понятно. Это довольно интересная перспектива. Возможно, stackoverflow.com/questions/9546635/… может пролить на это немного больше света.

Mikaal Anwar 10.05.2018 21:27

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

QMaster 10.05.2018 21:29

Позвольте нам продолжить обсуждение в чате.

QMaster 10.05.2018 21:48

Конечно ... Дайте этому чтение moz.com/blog/15-seo-best-practices-for-structuring-urls Пункт № 4 очень важен для вашего запроса.

Mikaal Anwar 10.05.2018 21:53

Я переместил это обсуждение в чат.

QMaster 10.05.2018 21:57

Чат здесь: chat.stackoverflow.com/rooms/170809/…

QMaster 10.05.2018 22:17

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

QMaster 10.05.2018 22:27

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

Mikaal Anwar 10.05.2018 22:30

Безусловно, мы закроем решение после обсуждения. Цените это, пожалуйста :)

QMaster 10.05.2018 22:37

Другие вопросы по теме