Repozytorium z Dapperem i Entity Frameworkiem

Odpowiedz Nowy wątek
2020-01-11 22:20
0

Tworzę sobie aplikację pisaną w CQRS. Jednym z użytych wzorców jest Repozytorium. Do pobierania danych (głównie query) chcę używać Dappera, a do command głównie EF. Pomysł wzięty z tego repozytorium: https://github.com/kgrzybek/modular-monolith-with-ddd. Już zacząłem coś tam pisać i wychodzi mi takie coś:

public class AlgorithmRepository : BaseRepository<Algorithm>, IAlgorithmRepository
{
    private IDatabaseConnection _connection;

    public AlgorithmRepository(IThinningDbContext thinningDbContext, IDatabaseConnection connection) 
        : base(thinningDbContext)
    {
        _connection = connection;
    }

    public async Task AddAlgorithmAsync(string algorithmName)
    {
        await _thinningDbContext.Algorithms.AddAsync(new Algorithm { Name = algorithmName });
    }

    public async Task<IEnumerable<Algorithm>> GetAlgorithmsByNameAsync(IEnumerable<string> names)
    {
        var parameters = new DynamicParameters();
        parameters.Add("@names", names);

        var connection = _connection.GetOpenConnection();   
        return await connection.QueryAsync<Algorithm>("GetAlgorithmsByName", parameters, commandType: CommandType.StoredProcedure);
    }
 }

Czy spotkaliście się z podejściem używania np insertów/deletów/updatów w EF, a selectów w Dapperze? Różnica w czasach między EF a procedurami przy insertach jest marginalna, zaś Dapper przy dobrze napisanych procedurach z selectami wygrywa. Czy ładowanie wszystkiego do jednego repozytorium (EF i procedury) wygląda dobrze?

edytowany 2x, ostatnio: Michał Szewczak, 2020-01-11 22:21

Pozostało 580 znaków

2020-01-14 08:01
0

Jakby kogoś ciekawiło co zrobiłem, zrezygnowałem z Repozytorium w przypadku EF. Do serwisów będę podawał klasę context i operował na niej. Repozytoria będą służyły tylko do selectów z Dappera. Dzięki za pomoc

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0