Перейти на PRO

Когда используется Application Storage в контексте ASP.NET Core?

Тип вопроса: ASP.NET Core Вероятность: 25% Категория: C# Разработчик

Ответ

В ASP.NET Core нет встроенной абстракции с точным названием "Application Storage". Этот термин может относиться к одному из следующих паттернов хранения данных на уровне приложения:

  1. In-Memory Storage (Память приложения):

    • Когда использовать: Для кэширования общих, часто читаемых данных, которые дорого вычислять и которые не критичны к потере при перезапуске приложения.

    • Как реализовать: Через IMemoryCache.

      public class MyService {
private readonly IMemoryCache _cache;
public MyService(IMemoryCache cache) => _cache = cache;

public async Task<MyData> GetDataAsync() {
    return await _cache.GetOrCreateAsync("myKey", async entry => {
        entry.SlidingExpiration = TimeSpan.FromMinutes(5);
        return await ExpensiveDatabaseCallAsync();
    });
}
}

  2. Статические поля или сервисы с Singleton lifetime:

    • Когда использовать: Крайне осторожно, для глобального, неизменяемого состояния (например, конфигурация, справочники), доступного всем запросам. Небезопасно для изменяемых данных из-за проблем с параллелизмом. 
      public static class AppState {
public static readonly IReadOnlyDictionary<string, string> Config;
}
// Или в Startup.cs:
services.AddSingleton<MySharedService>();

  3. Работа с файловой системой (App-специфичные папки):

    • Когда использовать: Для хранения файлов, специфичных для данного экземпляра приложения (логи, сгенерированные отчеты, временные файлы).

    • Как реализовать: Использовать IHostingEnvironment / IWebHostEnvironment для получения путей.

      public class FileService {
private readonly IWebHostEnvironment _env;
public FileService(IWebHostEnvironment env) => _env = env;

public string GetAppStoragePath() {
    return Path.Combine(_env.ContentRootPath, "App_Data");
}
}

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

Ответ 18+ 🔞

А, ну ты про "Application Storage" спрашиваешь? Такой, блядь, красивой абстракции, чтоб прямо так и называлась, в ASP.NET Core нету, понимаешь? Это ж не шкаф с одеждой, куда можно всё свалить. Тут надо думать, что именно ты хранить собрался, а то так и до пиздеца недалеко.

Смотри, варианта обычно три, и каждый — под свою конкретную жопу, прости за выражение.

1. Кэш в памяти (In-Memory Storage) Это когда тебе надо что-то быстрое, общее для всех, но если приложение перезапустится — и похуй, данные можно заново достать.

  • Зачем: Ну, например, справочник городов, который с базы тянется долго, а меняется раз в год. Или результаты каких-нибудь ебанутых расчётов.
  • Как: Через IMemoryCache. Красота, а не штука.
public class MyService {
    private readonly IMemoryCache _cache;
    public MyService(IMemoryCache cache) => _cache = cache;

    public async Task<MyData> GetDataAsync() {
        // Смотри, гениально: есть в кэше — отдаём, нет — идём в базу и кладём.
        return await _cache.GetOrCreateAsync("myKey", async entry => {
            entry.SlidingExpiration = TimeSpan.FromMinutes(5); // Живёт, если к нему обращаются
            return await ExpensiveDatabaseCallAsync(); // А это уже твои проблемы
        });
    }
}

2. Статика или Singleton-сервисы Вот тут, чувак, осторожно надо, а то на ровном месте себе ноги отстрелишь.

  • Зачем: Только для того, что не меняется вообще, или меняется раз в жизни. Глобальная конфигурация, какие-нибудь закешированные справочники, которые даже в кэш класть лень. Ни в коем случае не для данных, которые пишутся! Представь, десять потоков в одну переменную лезут — это же пиздец, а не код.
  • Как: Либо статический класс, либо сервис с временем жизни Singleton.
// Вариант "проще пареной репы", но и ответственность на тебе
public static class AppState {
    public static readonly IReadOnlyDictionary<string, string> Config; // Только readonly!
}

// Вариант поцивильнее, через DI
services.AddSingleton<MySharedService>(); // В Startup.cs или Program.cs

3. Файлы на сервере А это когда тебе надо реально что-то сохранить надолго, но в базу это совать — как молотком гвозди в монитор забивать.

  • Зачем: Логи, сгенерированные PDF-ки, картинки, какие-то временные файлы, которые само приложение рожает.
  • Как: Через IWebHostEnvironment узнаёшь, где корень приложения, и делаешь там свою папочку.
public class FileService {
    private readonly IWebHostEnvironment _env;
    public FileService(IWebHostEnvironment env) => _env = env;

    public string GetAppStoragePath() {
        // Вот тут и будет твоё "Application Storage" в виде папки App_Data
        return Path.Combine(_env.ContentRootPath, "App_Data");
    }
}

Короче, вывод простой, как три копейки: Сначала спроси себя — что я храню? Быстрый кэш, который не жалко? — IMemoryCache. Константы на всё приложение? — Аккуратный Singleton. Файлы? — Работай с файловой системой. Главное — не выдумывай велосипед и не пихай изменяемые данные в статику, а то будет тебе хиросима, а не приложение.

© ХакСобесов, 2026
support@hacksobesov.com