0

I am designing the different layers of a scheduler in c#. This is going to be a service running in the background without a GUI.

This is my baseline for the architecture (ofcourse only being a small snippet of the structure.

1

I am uncertain about "best-practice" in terms of archeticture. I have been reading about, POCOs, Value Objects, DTOs, Domain Model and from what I can understand, the presented below is a wrong approach to DTOs.

In my class "ScheduleDTP", I have several methods doing some relativ complex manipulations with date coming from the database. CalculatePriority is a simplified example of one of the methods

Database properties: ID, Name, Frequency, LastRun

Manipulated properties: Priority

The purpose of the jobmanager is to evaluate all schedules and on-demands.

To my understanding the DTO should only contain the data, and transfer that between the different layers. I also believe that this should not be the JobManagers resposibility either.

public class ScheduleDTO
{
    public Guid ID { get; set; }
    public string Name { get; set; }
    public int Frequency { get; set; }
    public DateTime LastRun { get; set; }

    //Calculation based on the values above
    public double Priority
    {
        get
        {
            return CalculatePriority();
        }
    }

    public double CalculatePriority()
    {
        return (DateTime.Now - LastRun.AddSeconds(Frequency)).TotalSeconds / 100;
    }
}

Should I create some different type of object, POCO, Domail Model, ..., that manipulates the data in the DTOs?

I really appreciate any help about how to construct the different layers or something that that could lead me in the right direction

MDK
  • 95
  • 1
  • 1
  • 8
  • Is a Scheduled Job actually different from an On Demand Job? Or, is it the way that a job is started that is different? Have you considered that maybe you do not need a Job Manager to start a job, but you instead need a Scheduler to trigger a job? There are too many details missing from your question for us to recommend a robust OO design. But what I can say is, your top layer looks suspiciously thin. – RWRkeSBZ Apr 11 '19 at 21:49

1 Answers1

0

This is normally handled by a Service layer (aka business logic layer, BLL, etc). The service layer's job is to hold the core business logic. There exists a long-standing argument about whether this layer should be used, or if it should be integrated into the domain objects. See this post for more details and do some googling about anemic domain models and transaction scripts.

In general, when I see anything called "Manager", I immediately flag it for close inspection. It is likely violating rules around Single Responsibility Principal. It ends up creating "God Objects" which are usually a very dangerous anti-pattern.

Rob Conklin
  • 8,806
  • 1
  • 19
  • 23