Blazor server: nvarchar в БД или Markdown в Azure Blob?

Для простого портфолио-сайта на Blazor server лучше хранить посты блога как Markdown-файлы (.md) в Azure Blob Storage — это проще в редактировании, дешевле и не требует базы данных. Хранение строк nvarchar в БД подойдет, если нужен мощный поиск или сложная структура метаданных, но добавит overhead на миграции и запросы. В реальных проектах вроде linkdotnet/Blog или downr разработчики выбирают Blob для скорости и удобства.

Содержание

• Хранение постов блога в Blazor server: обзор подходов
• Преимущества и недостатки nvarchar в базе данных для Blazor net
• Markdown-файлы в Azure Blob Storage: формат файла markdown и интеграция с Blazor
• Сравнение для простого портфолио-сайта на Blazor server
• Примеры реальных проектов с Blazor компоненты и azure storage
• Источники
• Заключение

Хранение постов блога в Blazor server: обзор подходов

Представьте: вы строите портфолио на Blazor с серверным рендерингом. Посты блога — это сердце контента. Два пути: засунуть текст в nvarchar-поля базы (SQL Server или SQLite) или выложить .md-файлы в Azure Blob Storage. Почему выбор важен? Blazor server рендерит на сервере, так что скорость загрузки и простота обновлений решают.

В первом случае пост — это запись в таблице: Title (nvarchar), Content (nvarchar(max)), Date, Slug. Легко индексировать, искать. Но база — это инфраструктура: подключения, миграции, бэкапы. Второй вариант: файлы Markdown в Blob. Каждый пост — index.md с YAML-метаданными в начале (title: “Мой пост”, date: “2026-02-26”). Blazor компоненты читают их по API или напрямую, парсят в HTML с помощью Markdig или подобного.

Что выбрать? Зависит от объема. Для 10-50 постов Blob выигрывает. А если тысячи с тегами и поиском — БД. В MikeCodesDotNET/Personal-Blog комбинируют: Blob для контента, SQLite для индекса метаданных. Умно, правда?

Преимущества и недостатки nvarchar в базе данных для Blazor net

Хранение в nvarchar — классика для Blazor net приложений. Плюсы очевидны: полнотекстовый поиск EF Core, транзакции, отношения (посты-комменты-теги). Обновить пост? Один UPDATE. Интеграция с Blazor Identity для админки — пара кликов.

Но минусы бьют по карману для портфолио. Во-первых, overhead: каждый деплой — миграции. Во-вторых, масштабирование: Azure SQL стоит от 5$/мес, плюс трафик. Третье — контент не “живой”: редактировать в SSMS или админке, без Git. А если сайт статический? БД тормозит SSR в Blazor server.

В Хабр Q&A отмечают: HTML/nvarchar гибче для админов, но Markdown проще в вебе. Для Blazor api это работает, если контент структурирован.

Markdown-файлы в Azure Blob Storage: формат файла markdown и интеграция с Blazor

Формат файла markdown — звезда статичных сайтов. Пост: YAML-фронтматтер + # Заголовок + текст + изображения. Храни в Blob: контейнер “posts/slug/index.md”. Цена? Pennies: 0.02$/GB + egress.

Интеграция с Blazor server тривиальна. В Startup.cs подключи Azure.Storage.Blobs. Компонент BlogPost.razor:

@inject IBlobServiceClient BlobClient

@code {
 private string content;
 protected override async Task OnInitializedAsync()
 {
 var blob = BlobClient.GetBlobContainerClient("posts").GetBlobClient($"{Slug}/index.md");
 content = await blob.DownloadContentAsync().GetAwaiter().GetResult().Content.ToString();
 // Parse с Markdig
 }
}

Кэшируй в Redis или MemoryCache — SSR летает. Плюсы: Git-редактирование, webhook на изменения (GitHub Actions → Blob), CDN для скорости. Минусы? Поиск — через Azure Cognitive Search (доп. бабки). Но для портфолио хватит client-side поиска.

В downr от Brady Gaster именно так: public-контейнер, YAML, Blazor routing по slug. Идеально для azure storage blazor.

Сравнение для простого портфолио-сайта на Blazor server

Портфолио — не Facebook. 100 посетителей/день, 20 постов. Blob Storage рвет БД:

• Стоимость: Blob ~0.1$/мес vs SQL 5-15$.
• Деплой: Файлы в Git → CI/CD → Blob. Нет миграций.
• Редактирование: VS Code + commit. Админка? Не нужна.
• Скорость: SSR Blazor читает файл за 50мс, парсит мгновенно.
• Масштаб: Blob бесконечно, БД — лимиты.

БД выигрывает в динамике: live-комменты, аналитика. Но для статичного блога? Перебор. Таблица:

Вопрос: а если рост? Добавь Cosmos DB позже. Но стартуй с Blob — как в linkdotnet/Blog.

Примеры реальных проектов с Blazor компоненты и azure storage

Реальные кейсы убеждают. linkdotnet/Blog от Steven Giesel: Blazor server, Markdown → HTML, хранение в Blob. Легко масштабировать, тесты bUnit.

Personal-Blog Mike James: Webhook на push → обновление SQLite-индекса из Blob. Blazor компоненты для роутинга, SSR.

downr Brady Gaster (Microsoft): Полный стек — Markdown в Blob, CDN, поиск опционально. Для Blazor ssr — шаблон.

На Хабре обсуждают: Markdown для блогов лучше nvarchar — меньше места, проще парсинг. Эти проекты показывают: для Blazor сайтов Blob — норма.

Хотите код? Клонируйте, запустите локально. Увидите, как azure blob storage blazor упрощает жизнь.

Источники

1. linkdotnet/Blog — Блог на Blazor server с Markdown в Blob Storage: https://github.com/linkdotnet/Blog
2. MikeCodesDotNET/Personal-Blog — Личный блог Blazor с webhook и Azure Storage: https://github.com/MikeCodesDotNET/Personal-Blog
3. bradygaster/downr — Markdown-блог на ASP.NET Core с Azure Blob и CDN: https://github.com/bradygaster/downr
4. Хабр Q&A — Сравнение Markdown vs HTML/nvarchar для блогов: https://qna.habr.com/q/673485

Заключение

Для портфолио на Blazor server выбирайте Markdown-файлы в Azure Blob Storage: минимум инфраструктуры, максимум удобства. nvarchar в БД — если поиск и динамика в приоритете. Стартуйте с Blob, как в проверенных проектах, — сэкономите время и деньги. А дальше масштабируйте по нужде.