C# 1001 notes
🔥 EF Core migrations - это компилятор схемы базы, а не кнопка «создать таблицу»
Опытный C#-разработчик не оставляет бизнес-инварианты только внутри SaveChangesAsync().
Проверку в приложении можно обойти прямым SQL, импортом данных, фоновым процессом или второй версией сервиса. Поэтому правила, нарушение которых делает данные некорректными, стоит закреплять в самой базе.
public sealed class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.ToTable("Products", table =>
{
table.HasCheckConstraint(
"CK_Products_Price_Range",
"[Price] > 0 AND [Price] <= 10000000");
});
builder.Property(x => x.Name)
.HasMaxLength(200)
.IsRequired();
builder.Property(x => x.NormalizedName)
.HasMaxLength(200)
.IsRequired();
builder.Property(x => x.Price)
.HasPrecision(18, 2);
builder.HasIndex(x => x.NormalizedName)
.IsUnique()
.HasDatabaseName("UX_Products_NormalizedName");
}
}
HasPrecision(18, 2) управляет физическим представлением decimal, но не проверяет допустимый диапазон цены. За это отвечает CHECK.
Уникальный индекс решает другую важную проблему - гонку между запросами.
if (!await db.Products.AnyAsync(x => x.Name == name))
{
db.Products.Add(product);
await db.SaveChangesAsync();
}
Два параллельных запроса могут одновременно пройти AnyAsync() и попытаться создать одинаковые записи. Только уникальное ограничение базы гарантированно остановит второй запрос.
Использовать для уникальности исходный Name тоже опасно. Результат будет зависеть от collation базы: Laptop, LAPTOP и Laptop могут считаться одинаковыми или разными. Поэтому часто сохраняют нормализованное значение:
product.NormalizedName = product.Name
.Trim()
.ToUpperInvariant();
После изменения модели создаём миграцию:
d
33 · 2.2K ·