2

I need to design a 'queue' of jobs (in a a very much UI oriented application) that can be run by a user and I need some other thoughts to pick optimal approach from ground up.

My jobs can be in a different states (imported, sent from elswhere, created by user, even to be just simulated with their imported recorded progress - following a whola different workflow), etc.

Therefore they can also pass thru the different states of their lifecycle, like being created, running, paused, validated or edited by a user (in case of invalid job parameters), imported or even in the process of being deleted (at least for logging or auditing).

Because of this, all jobs have to have their state at each point of time and they need to be managed somehow by a common logic.

There are also domain and application rules, that only one can be running/stopped/params edited in a time state, etc...

My main question is, whether to implement some kind of monolithic singleton controller for all states where it can answer state guards of each one of them (can/cant transition to other state) for all states and can call actions (other services) upon them, or whether to implement state machines inside of the jobs themselves and somehow call the services and related conditional logic from themselves (delete me/ edit me and so on).

I also need to tie this tightly to the UI, so that I have a list of tasks with the states visible for the user but I also have the separation of the concerns (job itself as a domain object of parameters - not states, UI).

This is just a brief description of my main problem, so I might update the requirements as suggestion or more questions that I forgot to address arrive.

1

I'd have a BaseJob class which will contain basic/shared properties and functionality. It can be an abstract class or just a plain base class, depending on the situation. If all jobs and states have similar behavior the base class can act as a controller and be abstract.

I'd also have State in each Job or may be the BaseJob can expect some sort of BaseState or GenericState. The State can contain the logic for next state or might even call some service for that, but you isolate that logic in that object.

For UI you'll need some sort of viewmodel anyway I'd think, it'll keep your business layer isolated, and contain the more UI/MVVM related concerns.

  • Hi AD. Inheritance (if I'd needed it), having a type of state in the job and having a ViewModel are sure things - no doubt about them. The point is about all those services around, that manage operations. Whether to use them from job object itself (which is now more of a data holder than a logic) or whether to create another service to manage the jobs - that's the dilemma. If I'd put the logic into the job class, it could overgrow the meaning of this business object with too much logic. – JankoHrasko Jul 27 '14 at 23:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.