Eric Anastas Eric Anastas - 3 months ago 19
C# Question

Should the input options be included with the results in a job/task queue?

I'm working on developing a job queue type system where Jobs can be added to a central queue. Processor then read jobs of the queue, run them, and store the results somewhere.

Each Job contains a list of tasks to perform in order and the options to use when running the Job and Tasks.

public class Job
{
public Guid JobId { get; set; }
public string Name { get; set; }
public DateTime Created { get; set; }
public string CreatedBy { get; set; }
IDictionary<string, string> Options { get; set; }
public IList<Task> Tasks { get; set; }
}

public class Task
{
public string Command { get; set; }
IDictionary<string, string> Options { get; set; }
}


The processors will return results for the Jobs and associated Tasks which identify if the Job and Tasks succeeded and include a message describing the results.

public class JobResult
{
public Guid JobId { get; set; }
public bool Succeeded { get; set; }
public string StatusMessage { get; set; }
IList<TaskResult> TaskResults { get; set; }
}

public class TaskResult
{
public bool Succeeded { get; set; }
public string StatusMessage { get; set; }
}


Yet if I were to create some kind of GUI or report showing the results of a Job I'd also want to show the details and options of the Job itself and not just the results alone. One way I've though to do this it to just add a reference to the
Job
to the
JobResult
class.

public class JobResult
{
public Guid JobId { get; set; }
public bool Succeeded { get; set; }
public string StatusMessage { get; set; }
IList<TaskResult> TaskResults { get; set; }

public Job Job {get; set;} <-- Add Job details to JobResult
}


Yet with this there isn't a direct association between the Task and TaskResult other then their position in the respective lists.

Alternatively, JobResult and Task could simply inherit from Job and Task respectively adding result status properties.

public class JobResult: Job
{
public bool Succeeded { get; set; }
public string StatusMessage { get; set; }
}

public class TaskResult: Task
{
public bool Succeeded { get; set; }
public string StatusMessage { get; set; }
}


How do systems like this typically work? It it a bad idea/code smell to be returning a copy of the input with the results?

Answer

I vote for associating JobResult with Job, because a Job isn't a JobResult and vice versa.

A JobResult has an associated Job, and in object-oriented programming world, a has a relationship means composition.