🧠 EF Core и Repository: когда паттерн мешает, а не помогает

👶 Junior: использует EF Core прямо в контроллере
🧑 Middle: строит BaseRepository, IUnitOfWork, IOrderRepository, IOrderDataAccess...
🧓 Senior: снова использует EF Core — без репозиториев

Почему так?

Сначала Repository Pattern кажется удобным:
4 метода на CRUD — всё аккуратно.
Но как только домен растёт, появляются проблемы:

- Репозиторий на каждую сущность
- Общая логика между сущностями? Куда её девать?
- Репозитории раздуваются до 10+ методов
- Тестируемость становится фикцией: мокаем абстракцию от абстракции

А что насчёт "мы вдруг сменим базу"?

В 99% случаев — не смените.
EF Core и так абстрагирует SQL.
А при переходе на NoSQL придётся переписывать модели, запросы и подход целиком.

А что с "это улучшает разделение ответственности"?

На деле:
- В сервисах висит куча репозиториев
- Общая логика размыта
- Больше обвязки, больше боли, меньше пользы

✅ DbContext уже реализует Repository и Unit of Work.
И это официально указано в исходниках EF Core.

🔥 17 000+ разработчиков уже ушли от репозиториев к практичному использованию EF Core в:
- N-Layered архитектуре
- Clean Architecture
- Vertical Slice
- Specification Pattern
- Интеграционных тестах с in-memory

📖 Подробнее:
https://antondevtips.com/blog/why-you-dont-need-a-repository-in-ef-core

#dotnet #efcore #architecture #backend #repositorypattern

💡 EF Core: как правильно настроить контроль конкурентности через RowVersion

В EF Core есть два удобных способа указать, что сущность должна использовать RowVersion для защиты от гонок при обновлении данных.

🟩 Вариант 1 - через атрибут в модели
Просто добавляете свойство типа byte[] и помечаете его [Timestamp]. EF автоматически будет обновлять версию записи и проверять конфликт изменений.

🟦 Вариант 2 - через Fluent API
Если не хотите засорять модель атрибутами, то же самое можно описать в OnModelCreating с помощью .IsRowVersion().

🧩 Пример из картинки показывает оба подхода — выберите тот, что лучше вписывается в вашу архитектуру.