Шаблон проектирования для отчетности / мониторинга прогресса длительных процессов

Любой может предложить хороший шаблон проектирования для отчетности / мониторинга состояния / хода длительных процессов. По сути, у меня есть кодовая база, которая получает объект «контекст данных»:

public class DataContext : IDataContext
{
    pulbic Dictionary Properties { get; private set; }

    // Additional properties removed for simplicity...
}

На основе предоставленного контекста создается объект Task (не TPL-Task) с различными подзадачами. Во время выполнения объект DataContext передается в различные подзадачи, которые могут его извлекать или обновлять.

Например, предположим, что основная задача - это задача «Копировать файлы».DataContext будет иметь такие свойства, как SourceFolder и TargetFolder, и, возможно, свойство FilterFiles (например, * .docx). Нашей основной задачей будет CopyFilesTasks, и у нее будет «конвейер» из подзадач - сканирование папок, сканирование файлов, фильтрация файлов, копирование файлов и т. Д.

То, что я ищу, является лучшим способом разрешить задаче / подзадаче сообщать о своем прогрессе вызывающему / исполнителю. В нашем примере выше текущие изменения могут быть просто «Скопированный файл ABC.docx ...» или, возможно, что-то более «сложное», например «Сканирование папки XYZ ...»

Я рассмотрел следующее параметры:

1. INotifyPropertyChanged : добавить свойство «Progress» в публичную строку DataContext

   Progress {get; установить {_progress = значение; RaisePropertyChanged («Прогресс»); }

   и иметь код, создавший объект DataContext, зарегистрированный в событии PropertyChanged. Однако это кажется слишком упрощенным подходом ...

2. ILog (используя любую структуру ведения журнала, которую вы предпочитаете): используйте экземпляр ILog в различных задачах / подзадачах, и пусть исполнитель основной задачи добавляет это собственный слушатель фреймворка ведения журнала. Однако это выглядело как изменение механизма ведения журнала для выполнения того, чего он не должен был делать.

3. Уди Дахан DomainEvents : исполнитель задачи может рассматривать DataContext как «домен», и поэтому мы можем попробуйте реализовать «EventHandler» для события «ProgressChanged». Теоретически это можно использовать даже для более сложных событий, которые происходят в определенных подзадачах ... Но, опять же, это похоже на принудительное применение концепции ...

Меня беспокоят такие вещи, как:

• Прогресс может это не единственное «событие», которое необходимо отслеживать - в нашем примере выше мы могли бы хотеть более определенные вещи, такие как FolderHandled, FileCopied и т. д., но мы можем не знать точных событий при выполнении задач (помните - подзадачи создаются на основе DataContext и могут привести к выполнению различных задач).
• Контекст выполнения задач еще не определен. На данный момент я просто планирую запускать задачи из приложения командной строки, поэтому вывод в командную строку необходим для отладки. Позже, когда я перенесу это в службу, я, возможно, захочу, чтобы «слушатель» обновлял базу данных с учетом прогресса задачи (например).