С разными вариантами сталкивался.

Паттерны: Репозиторий, Спецификация
Один большой класс получения данных из базы, миллион linq запросов размазанных по проекту с бизней логикой, которые часто могли дублироваться для разных юаев.

Какой вариант сейчас в тренде?

Здравствуйте, merge, Вы писали:

M>Паттерны: Репозиторий, Спецификация
M>Один большой класс получения данных из базы, миллион linq запросов размазанных по проекту с бизней логикой, которые часто могли дублироваться для разных юаев.

M>Какой вариант сейчас в тренде?
Тот, который подходит к вашей задаче.

Здравствуйте, merge, Вы писали:

M>Какой вариант сейчас в тренде?

EF Core

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, merge, Вы писали:

M>>Какой вариант сейчас в тренде?

G>EF Core

ну вот сейчас он и есть. только дублирования однородных запросов к базе очень мног и плюс на сложных апдейтах или массивных вставках он тормозит.
он хорош на ненагруженных логиках

в одном контролере есть вызов FeatureGetCars::GetCars и далее запрос через ef core
а в другом контролере есть вызов FeatureGetVehicles:GetCars и далее запрос через ef core такой же как выше просто с условием уточнением

Здравствуйте, merge, Вы писали:


G>>EF Core

M>ну вот сейчас он и есть. только дублирования однородных запросов к базе очень мног и плюс на сложных апдейтах или массивных вставках он тормозит.
M>он хорош на ненагруженных логиках

M>в одном контролере есть вызов FeatureGetCars::GetCars и далее запрос через ef core
M>а в другом контролере есть вызов FeatureGetVehicles:GetCars и далее запрос через ef core такой же как выше просто с условием уточнением
Дублирование логики — это не проблема EF. Это проблема размазанного слоя доступа к данным.
В EF её как раз несложно решить выделением общей логики в отдельный метод. В SQL это было бы сложнее и некрасиво.

Здравствуйте, merge, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, merge, Вы писали:

M>>>Какой вариант сейчас в тренде?

G>>EF Core
M>ну вот сейчас он и есть.

M>только дублирования однородных запросов к базе очень мног
Что мешает вынести одинаковые запросы и их общие части в отдельные методы и классы?

M>и плюс на сложных апдейтах или массивных вставках он тормозит.
https://learn.microsoft.com/en-us/ef/core/performance/efficient-updating?tabs=ef7

M>он хорош на ненагруженных логиках
Он хорош настолько настолько может быть хорош ORM в приложении. Остальное — дело прямых рук.

M>в одном контролере есть вызов FeatureGetCars::GetCars и далее запрос через ef core
M>а в другом контролере есть вызов FeatureGetVehicles:GetCars и далее запрос через ef core такой же как выше просто с условием уточнением
Почему нельзя вынести общие части запросов в одну функцию?

Здравствуйте, merge, Вы писали:


G>>EF Core

M>на сложных апдейтах или массивных вставках он тормозит.

Пример неплохо с бенчмарками, насколько все тормозит.
ЗЫ не забудьте засечь время на реализацию ef и ado решений.
да и какая версия корки? используйте 7-8 там очень сильно поработали на производительностью.

Здравствуйте, merge, Вы писали:

G>>EF Core

M>ну вот сейчас он и есть. только дублирования однородных запросов к базе очень много

Ну много, и что? Почему это проблема?

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, merge, Вы писали:

G>>>EF Core

M>>ну вот сейчас он и есть. только дублирования однородных запросов к базе очень много

vsb>Ну много, и что? Почему это проблема?


потому что когда надо что-то отрефакторить появляется 100500 мест какого-то поля и надо вникнуть что тут имел ввиду автор.
а если бы был один метод GetCars то всем бы было понятно что тут делается.

Да и в принципе иногда есть уже готовое, а из-за принципа что на каждый класс Feature пишется своя логика по работае с базой, то приходится писать своё вместо того чтобы подцепить готовое

Здравствуйте, gandjustas, Вы писали:


M>>только дублирования однородных запросов к базе очень мног
G>Что мешает вынести одинаковые запросы и их общие части в отдельные методы и классы?

про это был вопрос. как построить такой класс: паттерн какой-то или просто класс с кучей методов

Здравствуйте, merge, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:


M>>>только дублирования однородных запросов к базе очень мног
G>>Что мешает вынести одинаковые запросы и их общие части в отдельные методы и классы?

M>про это был вопрос. как построить такой класс: паттерн какой-то или просто класс с кучей методов
просто класс с кучей методов

M>>про это был вопрос. как построить такой класс: паттерн какой-то или просто класс с кучей методов
G>просто класс с кучей методов

Плюсую.
В последнее время отказался от репозиториев и т.п. обвязки.
Контекст EF-core + обычные extensions типа:

public static IQueryable<T> ById<T>(this IDbContext db, long id) { ... }

public static Task<T> ByIdAsync<T>(this IDbContext db, long id) { ... }

Дублирующаяся логика запросов уходит в эти extensions.
А IdbContext — минимальная обёртка над EFCore контекстом, чтобы не возникало искушение какие-то нестандартные вещи из EF DbContext заиспользовать:

public interface IdbContext { 
   IQueryable<T> Query<T>();
   Task SaveChangesAsync();
   Task AddAsync<T>(T entity);
   Task DeleteAsync<T>(T entity);
}

Для типового функционала этого достаточно.
При этом гибкость в плане Include, AsNoTracking и т.п. остаётся.

С одной стороны, абстракция протекает. А с другой — ну и пофиг, т.к. вероятность замены ef core на что-то иное — минимальная. Зато код сильно проще выходит и без десятков репозиториев.