Хорошая практика для объекта, который будет доступен и обновлен во многих классах в приложении?

Question

У меня есть приложение, которое будет запускаться раз в минуту. После завершения приложение запишет в таблицу журнала до своего выхода. Этот объект тесно отображает эту таблицу журнала:

class SendResult
{
    public DateTime StartTime { get; set; }
    public DateTime EndTime { get; set; }
    public TimeSpan ExecutionTime { get
    {
        return EndTime - StartTime;
    }
    public bool RequestChecked{ get; set; }
    public int RequestID { get; set; }
    public bool RequestRequiresFileSend { get; set; }

    public bool FilesRead { get; set; }
    public bool FilesSent { get; set; }

    public SendResult() { }
}

Каждое свойство будет обновляться в другой точке приложения. Я добился этого, объявив объект один раз и сделав его статичным:

class Program
{
    public static SendResult Result;

    public Program()
    {
        Result = new SendResult();
        Result.StartTime = DateTime.Now;
        // do stuff...
        Result.EndTime = DateTime.Now;
        LogUtility.Log(Result);
    }
}

.. и везде в приложении я просто звоню:

Program.Result.FilesRead = ...

Я знаю, что альтернативой является создание приложения вокруг SendResult, например:

SendResult result = new SendResult();
result.StartTime = DateTime.Now;

var request = new RequestHandler().CheckRequest();
result.RequestChecked = request.Checked;
result.RequestID = request.RequestID;
result.RequestRequiresFileSend = request.FileSendRequired;

var sendResult = new FileSender(request.ResuestID).Send();
result.FilesRead = sendResult.FilesRead;
// ...and so on

Но в случае, когда вам нужно вставить этот результат, отслеживающий после весь ваш код был написан, есть ли лучший способ, чем глобальный метод var, который я использовал?

Answer 1

Статические переменные обычно не очень хорошая идея, их практически нет в современных приложениях с Dependency Injection. Его использование добавляет состояние и увеличивает связь, что значительно усложняет, например, модульное тестирование всех ваших компонентов в изоляции.

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

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

Answer 2

Части кода, обобщенные как "do stuff", должны воспринимать экземпляр SendResult как зависимость, которая либо явно вставляется в них, либо, возможно, разрешается каким-либо иным способом, кроме прямой зависимости от доступа к статическому полю в Program. Вы можете передать ссылку напрямую, используя аргументы конструктора, свойства объекта или параметры метода. Косвенные способы сделать это можно реализовать с помощью контейнера IoC / DI . Идея состоит в том, чтобы уменьшить сцепление , что в большинстве случаев является хорошей идеей.

Потенциально, ваше приложение может получить выгоду от использования Архитектурного шаблона труб и фильтров , но только если у вас есть требования к масштабируемости и гибкости. В противном случае, введенные сложности будут контрпродуктивными для вашего конкретного случая.