Suggestions for Dispatcher.cs

Topics: Developer Forum, User Forum
Dec 18, 2009 at 1:47 AM

It would be nice to give flexibility to this class to allow an instance created with Settings as an argument.  That way if you want to be able to load/control the settings separately before starting the Dispatcher you can do so without your settings being overwritten by the Dispatcher on initialization.  This is particularly important to a deployment tool where it is nice and convenient to be able to programatically define the settings at run time via some external means such as from the system registry or another database or a calling application's own config file.

Below is the code in Dispatcher.cs as I've modified it.

/// <summary>
/// Program dispatcher.
/// </summary>
public class Dispatcher
{
    private readonly string _settingsFileName;
    private readonly Settings _settings;

    /// <summary>
    /// Initializes a new instance of the <see cref="Dispatcher"/> class.
    /// </summary>
    /// <param name="args">The arguments.</param>
    public Dispatcher(string[] args)
    {
        _settingsFileName = args != null && args.Length > 0
            ? args[0]
            : null;

        _settings = Settings.Load(_settingsFileName);
    }

    /// <summary>
    /// Initializes a new instance of the <see cref="Dispatcher"/> class.
    /// </summary>
    /// <param name="args">The arguments.</param>
    public Dispatcher(Settings settings)
    {
        if (settings == null)
            throw new ArgumentException("Settings cannot be null.");

        _settings = settings;
    }

    /// <summary>
    /// Runs this instance.
    /// </summary>
    public void Run()
    {
        if (_settings == null)
            throw new ArgumentException("Settings not initialized.");

        LogBanner();
        RunTasks(_settings);
    }

    /// <summary>
    /// Rus this instance from supplied settings.
    /// </summary>
    /// <param name="settings"></param>
    public void Run(Settings settings)
    {
        if (settings == null)
            throw new ArgumentException("Settings cannot be null.");

        LogBanner();
        RunTasks(settings);
    }

    /// <summary>
    /// Runs the tasks.
    /// </summary>
    private void RunTasks(Settings settings)
    {
        // need refactoring

        LogSectionHeader("Database Installation");
        DbTask dbTask = new DbTask(settings);
        if (dbTask.Validate())
        {
            dbTask.Execute();
        }

        LogSectionHeader("Reports Installation");
        PublishTask publishTask = new PublishTask(settings);
        if (publishTask.Validate())
        {
            publishTask.Execute();
        }
    }

    /// <summary>
    /// Logs the banner.
    /// </summary>
    private void LogBanner()
    {
        Logger.LogMessage(Settings.LogoBanner);
    }

    /// <summary>
    /// Logs the section header.
    /// </summary>
    /// <param name="title">The title.</param>
    private void LogSectionHeader(string title)
    {
        Logger.LogMessage(string.Format("\n--------------------------------\n{0}\n--------------------------------", title));
    }
}
Coordinator
Dec 18, 2009 at 9:26 AM

Great to hear suggestions for improvements and receive patches! I agree that it makes sense to intoduce the settings as a parameter for the dispatcher. It is a pretty natural follow-up from previous refactorings to the Settings class. I try to ensure that any changes to the code base are now accompanied by corresponding unit tests to ensure as much backwards compatibility as possible.