How to pass status information to the GUI in a loosely coupled application

Question

I have made my first attempt at using dependency injection to loosely couple a new application. My problem is how to pass status information back to the user. In the old days with all the code crammed into the GUI it was pretty easy if very messy and unmaintainable. The arrangement of classes is something like this (please do not check my UML skills - they are non existent):

If we take the right hand side. The AirportsInformationRepository just stores data and makes it available to the Controller when asked. At the start it gets the information using the Persist class to get files matching a given filter from the users hard drive. It uses the decompiler to extract information from a file. All this works fine and the information itself gets to the GUI as it should.

My problem is, in parallel, how to tell the user what is happening. This can occur in the decompiler, for example, if the file it gets cannot be decompiled or perhaps contains no data. It can occur in the Persist class if the config file is telling lies and some folder does not exist. Such issues should not stop the process unless there is a fatal error.

If there is a fatal error then it needs to get back to the user at once and the overall process should stop. Otherwise warnings can be collected through the process somehow and then displayed when the scan is completed.

I am familiar with logging and the application does have a logger that is monitoring the application for unhandled exceptions and other failures. This writes to disk and I use this like most would to deal with bugs. I don't want to use this for status reporting to the user since to be honest nothing is wrong with the app if a file is not found or the user entered an invalid path to the config file.

I have considered:

• accumulating a log in each class and passing it back to the consumer when the process completes (or fails). I am finding that really messy
• using events but if the consumer is subscribing and the events are passing up the chain in the same way as the log then I don't see that is much better. I guess an alternative is to have the GUI subscribe directly but it should not know anything about the decompiler....
• A home rolled logger that is either a static class or is instantiated in program.cs
• Some sort of messaging framework - which I admit I am not clear about but I think is rather similar to a central event handler whereby the GUI could subscribe to it without having to know anything about the other classes.

So to summarise. What is the best way to accumulate 'business as usual' status information and give it to the GUI at the end of a scan, at the same time being able to stop on a fatal issue.

Thanks in advance for reading this. Apologies for the length of the post.

EDIT I should have said that the app is using NET 3.5. I would change this to get an elegant solution but....

Answer 1

When you deal with a typical "flow" of processing, possibly even multithreaded/concurrent processing flow the best approach to take is "mailslots"/message pumps. By exchaging messages you can easily coordinate multiple layers of your application and that includes reporting errors, notifying the next chain of command etc.. I do not mean Windows messages, I mean something like:

public abstract class Message
{
   public abstract void Process();
} 

Then:

public class MessageQueue
{
   private Queue m_Queue;
   public void Post(Message msg) {....}
   public void Process() {.....}
}

Then you allocate a MessageQueue on every thread/processing tier of your app and pass messages like so:

    GUIMessageQueue.Post(
           new ErrorMessage("Internal async file reader ran out of buffer"));  

On GUI thread put a timer that read GUI queue and calls it's Process(). Now you can create many Message-derived work items to execute various tasks that very easily orchestrate between threads/logical tiers. Also, messages may contain references for datapieces that they relate to:

public AirplaneLandedMessage: Message { public Airplane Plane ...... }

Here is some real code that I use in massively parallel chain-processing system:

/// <summary>
/// Defines a base for items executable by WorkQueue
/// </summary>
public interface IWorkItem<TContext> where TContext : class
{
  /// <summary>
  /// Invoked on an item to perform actual work. 
  /// For example: repaint grid from changed data source, refresh file, send email etc... 
  /// </summary>
  void PerformWork(TContext context);

  /// <summary>
  /// Invoked after successfull work execution - when no exception happened
  /// </summary>
  void WorkSucceeded();

  /// <summary>
  /// Invoked when either work execution or work success method threw an exception and did not succeed
  /// </summary>
  /// <param name="workPerformed">When true indicates that PerformWork() worked without exception but exception happened later</param>
  void WorkFailed(bool workPerformed, Exception error);

}


/// <summary>
/// Defines contract for work queue that work items can be posted to
/// </summary>
public interface IWorkQueue<TContext> where TContext : class
{
  /// <summary>
  /// Posts work item into the queue in natural queue order (at the end of the queue)
  /// </summary>
  void PostItem(IWorkItem<TContext> work);

  long ProcessedSuccessCount{get;}
  long ProcessedFailureCount{get;}

  TContext Context { get; }
}

Answer 2

Well, the fatal errors are the easy part, they're simply handled via exceptions. The worker threads can just throw an exception when they run into a problem that prevent continuing on with work, and then at some point when it bubbles up to the UI layer you can catch the exception and display an appropriate error message to the user without actually crashing the application. You can use different types of exceptions and exception message to allow different problems to result in different UI responses.

As for indicating non-fatal statuses, you can use the IProgress interface for that. In your UI layer you can create a Progress instance that, when called, updates...whatever with the new status. You can then pass the IProgress instance down through the worker classes and fire it when you have information to provide.

Since you're pre 4.5 it's easy enough to rewrite this class.

public interface IProgress<T>
{
    public void Report(T parameter);
}

public class Progress<T>:IProgress<T>
{
    public event Action<T> ProgressChanged;

    public Progress() { }
    public Progress(Action<T> action)
    {
        ProgressChanged += action;
    }

    void IProgress<T>.Report(T parameter)
    {
        ProgressChanged(parameter);
    }
}

Note: the real Progress class marshals the event into the UI thread, I didn't add that part, so either add that in or do it in the event handler(s).