Я пишу приложение MVC, в котором я хочу, чтобы URL-адреса были оптимизированы для SEO, а поиск параметров осуществлялся по имени, а не по идентификатору. Так, например, вместо того, чтобы иметь что-то вроде этого:
/Products/Category/23
У меня будет что-то вроде этого:
/Products/Category/Books
И, похоже, что лучшие рекомендации - заменить пробелы дефисами вместо подчеркивания или% 20, поэтому категории из нескольких слов в приведенном выше примере будут выглядеть примерно так:
/Products/Category/Wall-Decorations
/Products/Category/some-other-name
Однако, что мы делаем, когда необработанное значение параметра на самом деле содержит дефисы? Например, что-то вроде
/Products/Category/E-Books
В этом случае дефис фактически является частью «электронных книг», а не разделителем слов.
Итак, если бы я был:
Products.Where(x => x.Name == parameter.Replace("-",""));
тогда «Электронные книги» в хранилище данных не будут совпадать с «Электронными книгами» (дефис заменен из параметра).
Единственное решение, которое я могу придумать, это сделать что-то вроде:
Products.Where(x=> x.Name.Replace("-","") == parameter.Replace("-",""));
таким образом, «Ebooks» (дефис заменен в хранилище данных) будет соответствовать «Ebooks» (дефис заменен из параметра), но это фактически приведет к тому, что в вашем хранилище данных значение с дефисами будет равно значению без дефисов. И хотя в этом надуманном примере «Электронные книги» и «Электронные книги» не должны никогда не существовать вместе, существуют другие сценарии, в которых присутствие дефисов важно. Например: названия компаний, URL-адреса, сохраненные поиски, которые включают тире для диапазонов дат и т. Д. (Не говоря уже о том, что если вы разрешаете пользователям создавать эти имена, то мы должны планировать все).
Итак, я нашел какой-то потенциальный обходной путь для определенных конкретных случаев, когда я могу сделать упрощающие предположения, но есть ли у кого-нибудь еще какие-либо предложения о том, как безопасно справиться с этим для всех сценариев?