Я должен встроить файлы CSS/JavaScript в веб-приложение?
Действительно ли возможно использовать объекты пространства имен System.Xml сделать задание здесь вместо того, чтобы использовать LINQ? Поскольку Вы уже упомянули, XmlNode. InnerXml точно, в чем Вы нуждаетесь.
4 ответа
Конечно, если бы любой, кто знал, что делал, мог бы использовать рефлектор сборки и извлечь JS или CSS. Но это было бы намного больше, чем просто использовать что-то вроде FireBug для получения этой информации. У обычного конечного пользователя вряд ли возникнет желание заниматься всеми этими проблемами, просто чтобы возиться с ресурсами. Любой, кто заинтересован в подобных вещах, скорее всего, будет злоумышленником, а не конечным пользователем. У вас, вероятно, есть много других проблем с безопасностью, если пользователь может использовать такой инструмент, как отражатель сборки в вашей DLL, потому что к этому моменту ваш сервер уже был скомпрометирован. Безопасность не была фактором в моем решении встраивать ресурсы.
Суть заключалась в том, чтобы не дать пользователям сделать что-нибудь глупое с этими ресурсами, например, удалите их, думая, что они не нужны, или иным образом подделайте их.
Также намного проще упаковать приложение для целей развертывания, потому что в нем задействовано меньше файлов.
Это правда, что DLL (библиотека классов) использовала по страницам больше, но это не делает страницы больше. ASP.NET генерирует контент, который необходимо отправить клиенту (браузеру). Клиенту отправляется не больше контента, чем необходимо для работы страницы. Я не вижу, как библиотека классов, помогающая обслуживать эти страницы, будет иметь какое-либо влияние на размер данных, передаваемых между клиентом и сервером.
Однако Rjlopes прав, может быть правда, что браузер не может для кеширования встроенных ресурсов JavaScript / CSS. Мне нужно проверить это, но я подозреваю, что Rjlopes прав: файлы JavaScript / CSS необходимо будет загружать каждый раз, когда выполняется обратная передача всей страницы на сервер. Если это подтвердится, это снижение производительности должно стать фактором вашего решения.
Я до сих пор не смог проверить разницу в производительности между использованием встроенных ресурсов, повторного ввода данных и отдельных файлов, потому что я был занят своими усилиями. Надеюсь, я займусь этим позже сегодня, потому что мне это очень интересно, и точка кеширования браузера, которую подняла Rjlopes, подняла.
Однажды мне пришлось принять такое же решение. Причина, по которой я решил встраивать свои ресурсы JavaScript / CSS в свою DLL, заключалась в том, чтобы предотвратить подделку этих файлов (любопытными конечными пользователями, купившими мое веб-приложение) после развертывания приложения.
Я сомневаюсь и сомневаюсь в правильности комментария Easement о том, как браузеры загружают файлы JavaScript. Я почти уверен, что встроенные файлы JavaScript / CSS временно воссоздаются ASP.NET перед отправкой страницы в браузер, чтобы браузер мог их загрузить и использовать. Мне это интересно, и я собираюсь провести свои собственные тесты. Я дам вам знать, как дела ....
-Фринни
Причина встраивания: браузеры не загружают файлы JavaScript параллельно. У вас есть условие блокировки, пока файл не будет загружен.
Причина против встраивания: вам может не понадобиться весь код JavaScript. Таким образом, вы можете без необходимости увеличивать пропускную способность / обработку.
Вы знаете, что если кто-то хочет подделать ваш JS или CSS, ему просто нужно открыть сборку с помощью Reflector, перейти к ресурсам и отредактировать то, что они хотят (вероятно, потребуется гораздо больше работы, если сборки подписаны).
Если вы встраиваете js и css на страницу, вы увеличиваете страницу (больше килобайт для загрузки на каждый запрос), и браузер не может кэшировать JS и CSS для следующих запросов. Хорошей новостью является то, что у вас меньше запросов (по крайней мере, 2, если вы похожи на меня и объединяете несколько js и css и один), плюс у javascripts есть проблема с последовательной загрузкой.