#asp.net-mvc #asp.net-mvc-4 #routing #routes #attributerouting
#asp.net-mvc #asp.net-mvc-4 #маршруты #атрибутивная маршрутизация
Вопрос:
Я работаю с атрибутивной маршрутизацией в asp.net веб-приложение mvc 4. Это единое приложение, поддерживающее 15 различных культур и более 20 языков. В результате моя таблица маршрутизации стала чрезвычайно большой, более 3000 маршрутов. Основная причина такого количества маршрутов заключается в том, что маршруты локализованы для каждого языка. Следствием этого является замедление поиска маршрута и, в свою очередь, низкая производительность сайта.
Я ищу способы повышения производительности. Итак, ищем советы. К сожалению, я не могу изменить свою структуру маршрутизации из-за бизнес-ограничений. Основная причина, по которой у меня так много маршрутов, связана с переводами — в таблице маршрутизации есть запись для каждого языка. Есть ли способ избежать этого?
Кроме того, я отмечаю в таблице маршрутизации записи для методов POST — требуется ли это? Можно ли избежать наличия записей в таблице маршрутизации для POST?
Существует ли какая-либо форма кэширования, которую можно включить, чтобы избежать поиска в таблице маршрутизации и вместо этого выполнять чтение из памяти?
Любые советы по оптимизации производительности при атрибутивной маршрутизации или при маршрутизации в целом были бы превосходны.
Комментарии:
1. Взгляните на superscribe.org для довольно крутой маршрутизации на основе графов.
2. Спасибо, но я бы предпочел оптимизировать, а не изменять, если это возможно.
3. Есть довольно старый пост от одного из оригинальных разработчиков Stack Overflow об оптимизации маршрутизации MVC3. Я не уверен, будет ли это по-прежнему применяться конкретно в MVC4 или вы даже выиграете от этого. samsaffron.com/archive/2011/10/13 /… . Я бы настоятельно рекомендовал измерить, где находятся ваши замедления, прежде чем вы начнете «оптимизировать».
4. Было бы неплохо, если бы мы могли установить RouteTable. Перенаправляет статическое свойство в новый экземпляр RouteCollection, который мы можем переопределить его методом GetVirtualPath amp; GetEnumerator. К сожалению, этот метод не является виртуальным, в противном случае вы можете использовать его как словарь или что-то еще, чтобы упростить поиск по языку и культуре в path.
Ответ №1:
Это сложный вопрос, поскольку никто четко не знает, насколько сложна ваша таблица маршрутов и с какими бизнес-ограничениями вы сталкиваетесь при реорганизации вашего веб-приложения. Итак, что я могу сделать, так это предложить вам изучить несколько вариантов:
- Используйте «area» в своем приложении. Area можно рассматривать как автономное веб-приложение со своей собственной таблицей маршрутов. Вы можете обратиться к этим ссылкам: http://www.codeproject.com/Articles/714356/Areas-in-ASP-NET-MVC и https://msdn.microsoft.com/en-us/library/ee671793 (v = против 100).aspx
- Используйте виртуальный каталог в IIS для декомпозиции вашего веб-приложения. Подобно «area», virtual directory позволяет разделить большое приложение на несколько меньших и сохранить прозрачность для конечных пользователей
Приведенные выше предложения могут основываться на локали или языке. Например, когда вы посещаете www.apple.com вы можете найти их локальный веб-сайт, например, в Канаде или Италии, настроенный как виртуальный каталог «www.apple.com/ca » или «www.apple.com/it «.
Надеюсь, это поможет! Генри