Comments 5
Хранить в БД линки на себя же… а потом делать скрытые селф-реквесты — да вы знаете толк в извращениях. Честно говоря, ожидал увидеть в статье решение с клиентским ресайзом картинки при аплоаде, интегрированным с ASP.NET.
Да, если бы это все не кэшировалось в CloudFront, то конечно лучше было бы конвертировать при загрузке в несколько разрешений, но тут есть свои минусы — если добавится новая страница с новым разрешением, то придется ресайзить огромное количество картинок, а тут все происходит на лету и очень редко.
Просто ресайзить «на лету» можно на уровне кода (контроллера в случае MVC), с кешированием и прочими плюшками, без создания отдельного реквеста и хранения кусков URL в базе. Причина в том, на сколько я понял, что ImageResizer предлагает универсальное решение для «домохозяек» со своим хендлером и настройками ресайза в строке запроса — с самого начала понятно, что это не безопасно, зато очень просто и удобно в использовании. Но не профессионально и не эффективно. Каждый запрос к картинке умножается на 2 абсолютно лишних телодвижений.
ImageResizer из коробки не требует никаких лишних телодвижений. При использовании плагинов семейства Performance все будет работать довольно достойно. В нашем же случае лишние телодвижения оправдывают себя, так как в общем-то каждая картинка ресайзится ровно один раз при первом запросе в CloudFront. Конечно можно было написать свой велосипед для изменения размеров на уровне контроллера, но опять же в нашем случае встает вопрос хранения кэша. Для хранения изображений мы все равно используем S3 и CF. Мы не храним пользовательский контент на своих серверах, а отправка картинки в S3 довольно затратная операция, к тому же все равно на выходе мы подсунем пользователю CF- ссылку, так что в нашем случае считаю использование данного решения для домохозяек вполне обоснованным.
Sign up to leave a comment.
Модуль ImageResizer для IIS