ASP.NET MVC синглтон или статический класс для передачи данных?

Question

Я создаю контроллер, который будет обслуживать комбинированные / минимизированные версии моего JavaScript и CSS.Мне нужно где-то вдоль строки определить, какие скрипты / стили должны быть загружены.

Когда запрос сделан, например, для style.css?VersionNumberHere, он проверит, находятся ли объединенные / минимизированные данные в * 1004.*, если так, выкладывай.В противном случае мне нужно найти определение, которое составляет style.css.

. Я создал Script/StyleBuilder (который наследуется от ContentBuilder), в котором будут храниться все пути, которые должны быть объединены, а затем сплющены(так что это будет определение style.css).

Где я должен хранить эти ссылки на «строителей»?Должны ли они быть в статическом классе или в синглтоне, который реализует интерфейс, чтобы его можно было протестировать?

Вот интерфейс, который реализует абстрактный класс ContentBuilder (вы можете легко представить реализацию):

public interface IContentBuilder : IEnumerable<string>
{
    string Name { get; }
    int Count { get; }
    string[] ValidExtensions { get; }
    void Add(string path);
    bool ValidatePath(string path);
    string GetHtmlReference(); // Spits out <script>, or <link> depending on implementation.
    string Build(); // Minifies, combines etc.
}

А вот в идеале , что я хотел бы сделать с этим:

ContentBuilderContainer.Current.Add("main.js", c => new ScriptBuilder()
{
    "/path/to/test.js",
    "/path/to/test2.js",
    "/path/to/test3.js"  
});

ContentBuilderContainer.Current.Add("style.css", c => new StyleBuilder()
{
    "/path/to/style.css",
    "/path/to/test.less"
});

Затем вывести весь HTML для всех зарегистрированных IContentBuilder:

ContentBuilder.Container.Current.BuildHtml();

Answer 1

Может быть, вам стоит проверить SquishIt . Немного больше информации об этом в этом блоге . Мы используем его в производстве.

Answer 2

Я сделал следующий интерфейс:

public interface IContentBuilderContainer
{
    int Count { get; }
    bool Add(string name, Func<IContentBuilder> contentBuilder);
    string RenderHtml();
}

А затем в результате ContentBuilderContainer:

public class ContentBuilderContainer : IContentBuilderContainer
{

    // Other members removed for simplicity.

    #region Static Properties

    /// <summary>
    /// Gets or sets the current content builder container.
    /// </summary>
    public static IContentBuilderContainer Current
    {
        get;
        set;
    }

    #endregion

    #region Static Constructors

    static ContentBuilderContainer()
    {
        ContentBuilderContainer.Current = new ContentBuilderContainer();
    }

    #endregion

}

Таким образом, единовременно ContentBuilderContainer живет одновременно.

Answer 3

Я помог написать код, который сделал это недавно.Вот общий обзор решения, которое было реализовано.Надеюсь, это даст вам хорошие идеи.

Конфигурация: Мы создали пользовательские элементы конфигурации, которые определяют ключ и соответствующий ему список каталогов.Таким образом, ключ JS связан с нашей папкой / Content / Scripts, а CSS связан с нашей папкой / Content / Styles.Я видел другие решения, в которых конфигурация позволяла перечислять отдельные файлы.

Контроллер: Контроллер был настроен на получение запросов, что-то вроде / Content / Get / JS и/ Content / Get / CSS.Контроллер использует ключ конфигурации и заголовки клиентских запросов, чтобы получить ключ кеша, который идентифицирует контент, который мы хотим обслуживать: JS-MSIE-ZIP, CSS-FFX и т. Д. Затем контроллер проверяет нашу службу кеша.Если содержимое отсутствует, оно объединяется, минимизируется, сжимается, кэшируется и затем обрабатывается.Удобно, что содержимое сжимается перед входом в кэш, а не каждый раз, когда оно обслуживается.

Просмотр: В представлении ссылки настраиваются следующим образом:

<link href="<%: Url.Action("Get", "Content", new { key = "CSS" }) %>" rel="stylesheet" type="text/css" />

Служба кэширования: Мы используем существующую службу кэширования, которая просто оборачивает кэш приложения.В какой-то момент мы, вероятно, переместим это в Velocity или что-то подобное.Если количество CSS и JS, которое мы кешируем, будет расти, мы, вероятно, изменим формат ключа на правильное имя файла и переместим содержимое в файловую систему.Но память довольно дешевая, посмотрим, что произойдет.

Причина: (если это имеет значение)

Мы сделали это, чтобы сохранить JavaScript для различных функций.в отдельных файлах в управлении исходным кодом без ссылки на все файлы в HTML отдельно.Поскольку мы конфигурируем наше содержимое по каталогам, а не по отдельным файлам, мы также можем запустить полную минификацию во время производственных сборок, чтобы несколько ускорить весь процесс выполнения.Тем не менее, мы по-прежнему получаем преимущество определения контента для обслуживания на основе клиентского браузера и кэшированных сжатых версий.

В процессе разработки система может быть настроена с быстрым изменением конфигурации, чтобы каждый запрос перестраивал JS.Файлы объединяются с именами файлов, введенными в комментарии для облегчения поиска, но содержимое не минимизируется, и нигде ничего не кэшируется.Это позволяет нам изменять, тестировать и отлаживать JS без перекомпиляции приложения.

Не удалось найти все эти функции в пакете, поэтому мы потратили пару дней и собрали его.Правда, некоторые функции были просто для развлечения, но именно поэтому нам нравится делать то, что мы делаем.=)

Answer 4

Прикрепите атрибуты кэширования к действиям вашего контроллера и кешируйте с помощью параметра, подобного этому:

[OutputCache(Duration = 7200, Location = OutputCacheLocation.Client, VaryByParam = "jsPath;ServerHost")]
[CompressFilter]
// Minifies, compresses JavaScript files and replaces tildas "~" with input serverHost address 
// (for correct rewrite of paths inside JS files) and stores the response in client (browser) cache for a day
[ActionName("tildajs")]
public virtual JavaScriptResult ResolveTildasJavaScript(string jsPath, string serverHost)
...