C# plugin architecture question

Question

Я работаю над приложением для мониторинга системы, аналогичным Nagios в C#. У меня есть интерфейс плагина, определенный как:

public interface IPlugin 
{ 
    PluginResult Execute(); 
} 

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

Прямо сейчас, в качестве примера, у меня пинг плагин:

public class PingPlugin : IPlugin 
{ 
    private const string RESULT_MESSAGE = "Average ms: {0}; Packet loss: {1}"; 

    private string _hostname; 
    private int _packets; 
    private int _timeout; 
    private int _warningTimeThreshold; 
    private int _warningLossThreshold; 
    private int _errorTimeThreshold; 
    private int _errorLossThreshold; 

    public PingPlugin(
     string hostname, 
     int packets, 
     int timeout, 
     int warningTimeThreshold, 
     int warningLossThreshold, 
     int errorTimeThreshold, 
     int errorLossThreshold) 
    { 
     _hostname = hostname; 
     _packets = packets; 
     _timeout = timeout; 
     _warningTimeThreshold = warningTimeThreshold; 
     _warningLossThreshold = warningLossThreshold; 
     _errorTimeThreshold = errorTimeThreshold; 
     _errorLossThreshold = errorLossThreshold; 
    } 

    public PluginResult Execute() 
    { 
     // execute the plugin 
    } 
} 

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

Answer 1

Считаете ли вы, что смотрите на Managed Extensibility Framework?

Answer 2

Вы можете применить атрибут [DefaultValue] к параметрам.

В C# для, вы можете использовать новый синтаксис для этого: int warningLossThreshold = 30,

Answer 3

Я голосовал +1 за MEF ответ тоже будет решить многие ваши проблемы.

Однако, если вы хотите сделать это без MEF, мне кажется, что вам не хватает какого-либо способа, чтобы плагины рассказывали ваше приложение через метаданные, о требуемых параметрах.

Один из возможных вариантов дизайна может заключаться в следующем: иметь интерфейс IPluginProvider, который может обнаружить ваше приложение. У этого должен быть конструктор без параметров, поэтому вы можете легко удалить экземпляр объекта new. Затем он должен иметь методы, которые возвращают любые метаданные (такие как «красивые имена» для параметров, которые требуются, какие разумные значения по умолчанию и т. Д.). Затем он должен включать метод CreateInstance, который принимает фактические параметры как IDictionary<string,object> и возвращает фактический пример IPlugin.

Answer 4

Вместо того, есть плагин конструктор определить параметры, вы могли бы рассмотреть что-то вроде этого:

public interface IPlugin 
{ 
    PluginResult Execute(Object parameters); 
} 

public class PingParameters 
{ 
    //Various parameters here, including [Description] and [DisplayName] attributes if you wish 
} 

public class ParametersTypeAttribute : Attribute 
{ 
    public Type Type { get; private set; } 

    public ParametersTypeAttribute(Type type) 
    { 
     Type = type; 
    } 
} 

[ParametersType(typeof(PingParameters))] 
public class PingPlugin : IPlugin 
{ 
    public PluginResult Execute(Object parameters) 
    { 
     return Execute((PingParameters) parameters); 
    } 

    private PluginResult Execute(PingParameters parameters) 
    { 
     //Your execution code here 
    } 
} 

Это дает большую гибкость для параметров, как вы можете добавить атрибуты, обеспечивают проверку сеттер и даже указать, дизайнер/конвертер для сетки свойств. Сетка свойств подключается непосредственно к объекту параметров.

Answer 5

Я не смотрел MEF (сделаю это сейчас).

У меня была проблема, почти идентичная вашей, я решил ее с помощью Attributes.
У меня есть пользовательский интерфейс, который (называет BL, который) использует отражение, чтобы показать все доступные «сервисы» (не более, чем соответственно оформленные классы).

Когда пользователь выбирает «службу», дополнительные атрибуты управляют пользовательским интерфейсом. Атрибут «схема» довольно прямолинейный и позволяет использовать любое количество параметров с любым именем.Вводя константы (с определением атрибута), вы можете стандартизировать общие вещи, такие как «имя», чтобы ваши службы были согласованными.

Все данные затем сохраняются в таблице пар ключей.

Замечательно, что вы можете просто сбрасывать новые/измененные «сервисные» сборки в мусорном баке - никакой дополнительной работы не требуется. Единственная зависимость - это сборка атрибутов - так что держите этот пост.

Исходный код находится в CodePlex, если вы хотите, чтобы «украсть» некоторые :)