Хранимые процедуры в Entity Framework против ADO.NET

Question

В одном из моих проектов я использую Entity Framework для подключения к SQL базе данных сервера. Из-за большого объема данных, таких как (1000 - 100000) вставка / обновление / удаление, мне пришлось использовать хранимые процедуры с пользовательскими типами таблиц в качестве параметра для повышения производительности.

Кроме того, эти операции вставки / обновления / удаления включают данные из нескольких других таблиц как зависимые. Итак, я использовал хранимую процедуру с правильной временной таблицей и CTE с запросами на соединение (это довольно сложное соединение) для достижения требуемого результата.

Достижение того же в Entity Framework (шаблоны репозитория) создает проблемы с производительностью. Мы также можем вызывать хранимые процедуры из Entity Framework

Теперь мой вопрос: что лучше в моем сценарии выше?

1. Вызов хранимой процедуры из Entity Framework (если да, предложите некоторые статьи для этого)
2. Вызов хранимой процедуры из ADO. Net

Заранее спасибо.

Удхай

Answer 1

Я бы избегал реализации шаблона хранилища с помощью Entity Framework / Entity Framework Core, поскольку он уже реализует шаблон хранилища. В частности, DbContext - это ваш UoW (единица работы), а каждый DbSet - это хранилище. Применение другого слоя поверх этого является избыточным и усложнит обслуживание.

Что касается ваших конкретных c вопросов, вы должны рассмотреть вопрос об использовании Dapper и Entity Framework, если все, что вы делаете вызывает хранимые процедуры, так как есть меньше накладных расходов и, возможно, лучшая производительность в зависимости от скрытых запросов. Он также будет обрабатывать отображение результатов в строго типизированный класс.

фрагмент кода

using (var connection = new SqlConnection("your connection string"))
{
    await connection.OpenAsync();

    var results = await connection.QueryAsync<SomeClass>("SomeStoredProc",
                  new {Param1 = value}, 
                  commandType: CommandType.StoredProcedure).ToList();

    // ... more code
 }