2013-07-24 5 views
2

У меня есть архитектурный вопрос.Расчет регистрации задач планировщика

Предположим, у нас есть планировщик и несколько подсистем. Некоторые из этих подсистем могут иметь действия, которые должны быть выполнены планировщиком.

У нас есть два способа реализации этой регистрации задач планировщика.

Один из способов - иметь метод в каждой подсистеме, называемый как RegisterSchedulerTasks, который будет вызван загрузчиком в приложении во время запуска приложения. В этом методе мы будем называть что-то вроде статического Scheduler класса, как это:

void Handler1(){ 
} 

void Handler2(){ 
} 

void RegisterSchedulerTasks() 
{ 
    Scheduler.RegisterHandler("E1", Handler1); 
    Scheduler.RegisterHandler("E2", Handler2); 
} 

"E1" и "E2" являются именами задач, которые будут иметь соответствующие настройки в планировщике конфигурации.

Другим подходом является использование, например, MEF. Каждая подсистема будет экспортировать набор ISchedulerTask с, и он не будет регистрировать эти задачи императивно. И с другой стороны приложения у нас будет SchedulerTasksRegistry, который будет импортировать набор из этих ISchedulerTask s.

Во всех подходах мы будем иметь карту в конфигурации, которая будет содержать временную шкалу планирования для каждой задачи, идентифицированную в обоих подходах по ее названию.

Я склонен к второму подходу, но для этого недостаточно аргументов. Вероятно, единственным аргументом является то, что первый подход означает более высокую статическую связь подсистем.

Я прав, второй подход лучше? Каковы аргументы для любого из этих подходов?

+0

Мой вопрос касается не только планировщика. Например, можно задаться аналогичным вопросом о некоторых фабриках - мы можем построить этот завод неявно с помощью MEF, который будет искать все доступные реализации интерфейса, которые возвращаются фабрикой, а с другой стороны мы можем создать этот завод по необходимости с каким-то жестко закодированным переключателем. –

ответ

0

Здесь я бы использовал шаблон «Цепь ответственности». Этот шаблон

'Предотвращает связывание отправителя запроса с приемником, предоставляя более одного объекта возможность обработать запрос. Цепочка возвращаемого объекта и передайте запрос по цепочке, пока объект не обработает его. '

Пример использования этого рисунка может быть найден here.

Надеюсь, это поможет.

+0

Извините, я не понимаю, как использовать этот шаблон в моем случае. Вы можете объяснить, пожалуйста? –

Смежные вопросы