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

BE>Как бы это реализовать?

Предложите ему купить Оракл. Там подобное уже наверняка реализовано, через те же логи аудита.

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

RD>Вообще задача хорошо ложится на Event Sourcing парадигму. Тогда лог изменений (поток событий) будет из коробки.
RD>Но и в классической схеме с репозиториями можно попробовать построить pipeline обработки входящих запросов по CQRS схеме.
RD>Т.е. чтобы на каждую бизнес транзакцию был свой IQueryHandler<T>/ICommandHandler<T>.
RD>Тогда поверх можно единожды написать универсальный декоратор, который будет логировать контекст (пользователь, IP и т.п.), входные параметры и результаты выполнения.

Да, мы к этому варианту и пришли. Будем пробовать так делать.

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

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

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

K>>>>А цель этого какая?
BE>>>Залогировать всЁ. В том числе чтение. Да, там будут терабайты логов. Требование такое.

W>>Так цель-то какая? Аудит? Восстановление после сбоя? История изменений?

BE>История изменений

Допустимо ли, что у пользователя, имеющего доступ к таблице, по которой нужно хранить историю, будет доступ к истории?

Если допустимо, то можно сделать таким образом:
Для каждой таблицы, по которой нужна история, сделать таблицу с историей изменений, в которой будут колонки с такими-же именами и колонки с именами <имя колонки>_PREV.
На INSERT, UPDATE и DELETE повесить триггеры в которых будет делаться вставка в таблицу с историей.

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

В общем повесили все это дело на pipeline медиатора ()Behaviors:

public async Task<TResponse> Handle(TRequest request, CancellationToken cancellationToken, RequestHandlerDelegate<TResponse> next)
{
    //Trace.WriteLine("Before handler");

    var response = await next();

    //Trace.WriteLine("After handler");
    
    bool IsLog = response is ILoggedResponse;

    if (IsLog)
    {
        string output = JsonConvert.SerializeObject(response);

        _log.LogInformation($"User {userId} has access for data: {output}");
    }

    return response;
}

Понужу чуток.
Имхо, если TRequest/TResponse — это DTO-шки, то лучше такое атрибутами решать (e.g. [Autolog]), а не маркерными интерфейсами.
Оно чище/расширяемей получится.
Скажем, если появятся разные форматы логирования (e.g. минимальный/подробный), это будет доп.поле в атрибуте,
а не лишний член в ILoggedResponse, который каждому из наследников придется реализовывать.

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

RD>Понужу чуток.
RD>Имхо, если TRequest/TResponse — это DTO-шки, то лучше такое атрибутами решать (e.g. [Autolog]), а не маркерными интерфейсами.
RD>Оно чище/расширяемей получится.
RD>Скажем, если появятся разные форматы логирования (e.g. минимальный/подробный), это будет доп.поле в атрибуте,
RD>а не лишний член в ILoggedResponse, который каждому из наследников придется реализовывать.

Да, пожалуй. Учтем на будещее.

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

RD>Понужу чуток.
RD>Имхо, если TRequest/TResponse — это DTO-шки, то лучше такое атрибутами решать (e.g. [Autolog]), а не маркерными интерфейсами.
RD>Оно чище/расширяемей получится.
RD>Скажем, если появятся разные форматы логирования (e.g. минимальный/подробный), это будет доп.поле в атрибуте,
RD>а не лишний член в ILoggedResponse, который каждому из наследников придется реализовывать.
Предположу, что по скорости исполнения маркерный интерфейс будет быстрее.