Блог

Я ищу быстрый и элегантный способ преобразования идентификаторов моих объектов в описательные имена, чтобы мои автоматически созданные маршруты выглядели как:

/products/oak-table-25x25-3-1

вместо

/products/5bd8c59c-fc37-40c3-bf79-dd30e79b55a5

В этом примере:

 uid  = "5bd8c59c-fc37-40c3-bf79-dd30e79b55a5"
name = "Oak table (25x25) 3/1"
  

Я даже не знаю, как можно назвать эту функцию, чтобы я мог поискать ее в Google.

Проблема, которую я вижу до сих пор, заключается в уникальности этого «url-object-name», например, если у меня есть две таблицы oak 25×35 в БД, и их имена отличаются слишком мало, чтобы иметь уникальное URL-имя, но достаточно, чтобы обмануть ограничение уникальности в БД.

Я подумываю написать эту функцию для преобразования имени в SQL в виде UDF, затем добавить вычисляемое поле, которое его возвращает, затем уникальное -ограничение этого поля.

Есть ли какой-нибудь более распространенный способ достижения этого?

Один из методов используется stackoverflow.com что в вашем случае было бы:

/продукты/5bd8c59c-fc37-40c3-bf79-dd30e79b55a5/дубовый стол-25×25-3-1

Это гарантирует уникальность, однако длина UUID может быть сдерживающим фактором. Вы можете рассмотреть возможность добавления последовательного значения идентификатора int или bigint в таблицу products в дополнение к полю uniqueidentifier. Это, однако, потребовало бы дополнительного индекса в этом столбце для поиска, хотя аналогичный индекс потребовался бы для URL, имеющего только строку описания. Еще одним методом было бы использовать хэш-значение, например, с указанием даты, которое вы можете составить с описательным именем. Проще полагаться на последовательное значение идентификатора, генерируемое базой данных, но если вы планируете использовать механизмы хранения NoSQL в будущем, вы можете рассмотреть возможность использования сгенерированного извне хэш-значения для добавления.

Идентификатор должен иметь 2 свойства: он должен быть уникальным и неизменяемым. Если вы можете гарантировать, что это /products/oak-table-25x25-3-1 никогда не изменится на /products/oak-table-25x25-3-1-1 (помните, у пользователя могут быть закладки, которые не должны возвращать код состояния 404) — вы можете использовать name в качестве параметра URL и получить запись по этому параметру.

Если вы не можете гарантировать уникальность или хотите выбрать запись быстрее — используйте next:

1. /products/123/oak-table-25x25-3-1 — получить запись по идентификатору (123)
2. /products/123/blablabla — следует перенаправить на first, потому что blabla не существует или имеет другой идентификатор
3. /products/123 — следует перенаправить на первый

И попробуйте использовать более короткие идентификаторы — помните, что в Web 2.0 URL является частью пользовательского интерфейса, а пользовательский интерфейс должен быть дружественным.

Маршрутизация MVC (действия) будет обрабатывать пробелы и косые черты в имени. Он будет кодировать их как , а затем правильно декодировать.

Таким образом, ваш URL будет /products/oak table 25x25-3/1

Я сделал нечто очень похожее в платформе электронной коммерции, над которой я работаю.

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

Решение заключалось в реализации .Функциональность NET MVC «только для URL slug». Менеджер продукта создает «slugges» для каждого продукта, которые уникальны и назначаются продуктам. Они ссылаются на продукт, но идентификатор продукта и название могут быть изменены в любое время.

Это позволяет:

domain.com/oak-table-25×25-3-1

чтобы указать на:

/products/5bd8c59c-fc37-40c3-bf79-dd30e79b55a5

(Та же функциональность может быть использована и для категорий, так что domain.com/tables может указывать на domain.com/category/5b38c79c-f837-42c3-bh79-dd405479b15b5 )

Я задокументировал, как я это сделал:http://makit.net/post/3380143142/dotnet-slug-only-urls