ASP.NET (MVC) Обслуживание изображений

Question

Я создаю приложение MVC 3 (хотя оно применимо и к другим технологиям, например, ASP.NET Forms), и мне было просто интересно, возможно ли (с точки зрения производительности) обслуживать изображения из кода, а не использовать прямой виртуальный путь (например, обычно).

Идея состоит в том, чтобы улучшить общий метод обслуживания файлов до:

1. Применить проверки безопасности
2. Стандартизированный метод обслуживания файлов на основе значений маршрута
3. Возврат модифицированных изображений (если требуется), например различные размеры (хорошо, это будет использоваться только экономно, поэтому не связывайте это с вопросом производительности выше).
4. Выполнение бизнес-логики перед разрешением доступа к ресурсу

Я знаю, КАК это сделать, но я не знаю, ЕСЛИ я должен это сделать.

1. Какие проблемы с производительностью (если есть)
2. Случается ли что-то странное, например, изображения загружаются только последовательно (может быть, именно так в настоящее время и работает HTML, я не уверен - здесь я вижу свое невежество).
3. Все, что вы можете придумать.

Надеюсь, все это имеет смысл!

Спасибо, Dan.

UPDATE

ОК - давайте определимся:

Какое влияние на производительность оказывает использование этого типа метода для обслуживания всех изображений в MVC 3 с использованием потока памяти? Примечание: URL-адрес изображения будет GenericFetchImage / image1 (и просто для простоты - все мои изображения в формате JPEG).

public FileStreamResult GenericFetchImage(string RouteValueRefToImage)
{
    // Create a new memory stream object
    MemoryStream ms = new MemoryStream();

    // Go get image from file location
    ms = GetImageAndPutIntoMemoryStream(RouteValueRefToImage);

    // return the output as a file
    return new FileStreamResult(ms, "image/jpeg");
 }

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

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

СПАСИБО!

Answer 1

Подобный вопрос задавался ранее ( Может ли контроллер ASP.Net MVC возвращать образ? ), и похоже, что влияние на производительность очень мало для обслуживания изображений из действий по сравнению с непосредственными действиями.Как отмечается в принятом ответе, разница, похоже, составляет порядка миллисекунды (в этом тестовом примере около 13%).Вы можете повторно запустить тест локально и посмотреть, какая разница на вашем оборудовании.

Лучший ответ на ваш вопрос , если вы должны его использовать, это от ответа до (другого) аналогичного вопроса (выделено мной):

НЕ беспокойтесь о следующем: вам нужно будет повторно реализовать стратегию кэширования на сервере, поскольку IIS управляет ею для статических файлов, запрашиваемых напрямую.Вам также необходимо убедиться, что вы управляете кэшированием на стороне клиента с правильными заголовками, включенными в ответ. В конечном итоге, просто спросите себя, является ли повторное изобретение метода обслуживания статических файлов с сервера тем, что отвечает потребностям вашего приложения.

Для решения конкретных случаев, которые вы предоставили с помощьювопрос:

1. Применение проверок безопасности

   Это можно уже сделать с помощью интегрированного конвейера IIS 7 .Соответствующий бит из документации:

   Разрешение служб, предоставляемых как собственными, так и управляемыми модулями, применять ко всем запросам независимо от обработчика.Например, управляемую проверку подлинности с помощью форм можно использовать для всего содержимого, включая страницы ASP, CGI и статические файлы .

2. Стандартизированный метод обслуживания файлов на основе значений маршрута

   Если я правильно читаю документацию, вы можете вставить модуль заранеев конвейере достаточно переписать входящие URL-адреса, чтобы они указывали на статические ресурсы и позволяли IIS обрабатывать запрос оттуда. (Ради полноты есть также связанный вопрос, касающийся сопоставления маршрутов с магами: Как маршрутизировать изображения с использованием маршрутизации ASP.Net MVC? )

   Расширение возможностей компонентов ASP.NET для обеспечения функциональности, которая ранее была им недоступна из-за их размещения в конвейере сервера.Например, управляемый модуль, обеспечивающий функциональность перезаписи запроса, может переписать запрос до любой обработки сервером , включая аутентификацию.

   Существуют также довольно мощные функции перезаписи URL , которые более или менее поставляются с IIS.

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

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

4. Выполните бизнес-логику, прежде чем разрешить доступ к ресурсу

   Если вы выполняете бизнес-логику для генерации указанных ресурсов (например, диаграммы ) или, как вы упомянули изображение с изображением капчи, то да, у вас, по сути, нет другого выбора, кроме как сделать это таким образом.