С# как "зарегистрировать" "плагины" класса в класс обслуживания?

Ответ 1

Для меня MEF/MAF - это то, что вы могли бы сделать последним в такой проблеме. Первый шаг - выработать свой дизайн. Я бы сделал следующее:

• Внедрите шаблон дизайна декоратора (или подобный структурный шаблон по вашему выбору). Я выбираю декоратор, так как это похоже на то, что вы делаете, добавляя определенные классы с общей функциональностью, которые не определены в этих кланах (например, композиция кажется предпочтительной в вашем примере, а не в наследовании). См. Здесь http://www.dofactory.com/net/decorator-design-pattern

• Подтвердите шаг 1 POC для разработки, если он будет делать то, что вы хотите, если он будет добавлен как отдельная dll (то есть, создав другой CSProj, испеченный во время сборки).

• Оцените, подходит ли MEF или MAF для вас (в зависимости от того, какой вес вы хотите поместить). Сравните их с другими методами, такими как микросервисы (которые философски изменили бы ваш нынешний подход).

• Внедрите свой выбор горячей замены (MEF, вероятно, наиболее логичен на основе информации, которую вы предоставили).

Ответ 2

Вы можете использовать Reflection. В классе Service1 определите список типов BaseAction, которые вы хотите предоставить:

List<Type> providedActions = new List<Type>();
providedActions.Add(typeof(DoSomething1));
providedActions.Add(typeof(DoSomething2));

Затем вы можете написать один метод DoSomething, который выбирает правильный BaseAction во время выполнения:

public async Task<Obj1<XXXX>> DoSomething(string actionName, ....params....)
{
    Type t = providedActions.Find(x => x.Name == actionName);

    if (t != null)
    {
        var action = (BaseAction)Activator.CreateInstance(t);

        return await action.Go(....params....);
    }
    else
        return null;
} 

Недостаток заключается в том, что Клиент не знает действий, предоставляемых службой, если вы не реализуете ad-hoc-метод, например:

public List<string> ProvidedActions()
{
    List<string> lst = new List<string>();
    foreach(Type t in providedActions)
        lst.Add(t.Name);
    return lst;
}

Ответ 3

Может быть RealProxy может вам помочь? Если вы создаете интерфейс ICarService, который наследует IAction1 и IAction2, вы можете создать прокси-объект, который будет:

• Найти все интерфейсы ICarService наследует.
• Находит реализации этих интерфейсов (используя действия factory или отражение).
• Создает список действий для службы.
• В Invoke метод будет делегировать вызов одному из действий.

Таким образом, у вас будет интеллект, как вы хотите, и действия будут создавать блоки для служб. Какой-то вид наследования с несколькими наследствами:)

Ответ 4

В этот момент я действительно испытываю искушение сделать следующее:

• Создайте свой собственный атрибут класса RegisterAction (точно так же, как я написал на моем "теоретическом" примере)
• Расширьте Процесс сборки Visual Studio
• Затем на моем public class LazyProgrammerSolutionTask: Microsoft.Build.Utilities.Task попробуйте найти классы обслуживания и определить атрибуты RegisterAction.
• Затем для каждого из них я буду вводить с использованием отражения свой собственный метод (тот, который я всегда копирую вставку)... и, конечно же, получить "подпись" из соответствующего целевого класса "действие".
• В конце концов, скомпилируйте все снова.
• Тогда мой "следующий проект", который будет потреблять этот проект (библиотека), будет иметь интеллект, который я ищу....
• Одна вещь, что я действительно не уверен, это то, как "debug" будет работать над этим....

Так как это еще и теоретически (BUT ВОЗМОЖНО) решение, у меня пока нет исходного кода.

Между тем, я оставлю этот вопрос открытым для других возможных подходов.