Объединение ресурсов через bundle.config vs BundleConfig.cs в ASP.NET 4.5 WebForms

Относительно ASP.NET 4.5 нового System.Web.Optimization/Microsoft.AspNet.Web.Optimization:

Может ли кто-нибудь объяснить разницу в использовании ресурсов связывания с помощью файла класса BundleConfig.cs в отличие от файла bundle.config xml?

Я видел некоторые статьи, в которых показано объединение js и css в BundleConfig.cs, а другие. показывая связывание js в BundleConfig.cs и css в файле bundle.config.

Я предполагаю, что я не понимаю № 1), почему вы просто не делали бы их как один конкретный способ для простоты - и № 2), почему кто-то предпочел бы жестко закодировать ресурсы, подобные этому в файле класса? Это похоже на гораздо более динамичный подход, чтобы просто помещать их в XML файл, который может быть изменен "на лету", если это необходимо.

Кажется, что больше статей на самом деле склоняются к использованию BundleConfig.cs, чем что-либо еще. Есть ли какой-то определенный pro или con, который поощряет это?

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

Спасибо -

Ответ 1

эта документация объясняет все это лучше, чем я когда-либо мог

http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification

Одна из самых приятных вещей:

Структура связывания следует нескольким общим соглашениям, таким как:

Выбор файла ".min" для выпуска, когда "FileX.min.js" и "FileX.js" существовать.

Выбор версии ".min" для отладки. Игнорирование "-vsdoc" файлы (например, jquery-1.7.1-vsdoc.js), которые используются только IntelliSense.

Ответ 2

Насколько я могу судить, принятый ответ вообще не отвечает на вопрос. В нем обсуждаются преимущества структуры связывания, но не так, как использование BundleConfig.cs отличается от использования файла bundle.config.

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

Для bundle.config действительно существует только одно преимущество, но оно большое. Используя его, вы можете управлять пакетами, не касаясь кода вообще. Это означает, что вы можете вносить изменения без перекомпиляции, упрощая быстрое развертывание. Кроме того, это означает, что ваш сторонний разработчик, который будет лучше всего разбираться в файлах, которые должны быть в комплекте, может определить пакеты без необходимости работать с любым внутренним кодом.

Однако существует множество ограничений на то, что вы можете указать в Bundle.config. Например, вы не можете указать какие-либо пользовательские преобразования, которые будут применяться к отдельным элементам или пакетам. Единственными свойствами пакета, которые вы можете установить, являются Path, CdnPath и CdnFallbackExpression. Вы не можете установить свойства Orderer или EnableFileExtensionReplacements. У вас нет возможности включить каталог, включающий все подкаталоги (например, с помощью метода IncludeDirectory). В принципе, существует много функций, доступных только через внутренний код. Конечно, многое из этого вы могли бы установить с помощью внутреннего кода для извлечения пакета, который был определен в файле bundle.config, а затем манипулирования. Но если вы собираетесь это сделать, вы также можете создать пакет в back-end.

Моя личная философия - использовать bundle.config, если мне не нужно что-то делать с пакетом, который невозможен. Однако я согласен с тем, что иметь их всех в одном месте идеально. Если я решила, что мне нужно использовать класс, то я буду использовать это для всех моих пакетов этого типа (иногда я помещаю свои пакеты JS в класс и мои узлы CSS в .config файл, хотя). Я уверен, что некоторые вполне разумные люди не согласятся с этим процессом.

Ответ 3

Может ли кто-нибудь объяснить разницу в использовании связующих ресурсов используя файл класса BundleConfig.cs, в отличие от bundle.config xml файл?

Разница в том, что вам придется читать, анализировать и загружать содержимое пакета bundle.config во время выполнения. Следовательно, использование файла класса BundleConfig.cs может быть проще.

1), почему вы просто не делали бы их как один конкретный способ для простоты

Полностью согласен.

2), почему кто-то предпочитает жесткие коды ресурсов, подобные этому в файле класса?

Проще говоря: легко понять.

Кажется, что гораздо более динамичный подход просто поместить их в xml файл, который может быть изменен "на лету" при необходимости.

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

Кроме того, если есть реальная документация по System.Web.Optimization, я хотел бы знать местоположение (потому что я уверен, что не могу его найти).

Уже ответил выше, но я бы повторил: http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification