Как вынести логику работы в отдельные .dll? И как такое называется?

Question

[Макс Максимов]

Дано: веб-сервис рассылки данных на WebAPI с базой клиентов. Каждый клиент принимает рассылку по своему требованию (протокол, поля данных, иногда даже требуется отправлять файлом (.xls, .mdf, ...)).
Надо:

1. Вынести бизнес-логику генерации запроса-отчёта для каждого клиента в отдельную .dll
2. Так как, веб-сервис отправляет рассылку каждые 2 минуты, нужно прикрутить сканнер .dll-ок для определённого клиента. Чтобы изменять их было легко, без перезапуска или остановки приложения.

Вариант с дополнительными полями/таблицами, описывающих требования клиентов, и написание отдельной функции не подходит. Потому что там придётся учитывать всё. Может быть такое, что клиент новый появится и скажет, вот я хочу принимать данные в .xls/.mdf/.dba через POST/proxy и тд. Поэтому нужна такая гибкая архитектура, где не придётся учитывать всё. А всё добавляется как отдельная функция в .dll для основного веб-приложения при необходимости, то есть, когда такой клиент с определёнными требованиями появляется. Не за чем сейчас писать логику генерации отчёта по всем протоколам, файлам и иными требованиями.

Прошу подсказать с решением данной проблемы и поделиться называнием такого вида архитектуры. Или предложить альтернативный вариант решения данной задачи. Чтобы не надо было без конца ре-деплоить приложение, а заменять .dll-ки для каждого клиента при надобности.

Answer 1

[Петр]

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

Конечно не совсем понятно из вашего описания, что вы конкретно хотите. Но я предположу, что скорее вам подойдет Workflow, когда все разбиваете на маленькие задачки, которые вы сможете помещать уже в dll, а далее просто описывать сценарий.

Comments

[lam0x86]

Вот тут более подробно описано, как сделать безопасную загрузку и выгрузку плагина в отдельном AppDomain'е: https://stackoverflow.com/a/4157237

[Петр]

lam0x86: То что описано не затрагивает много моментов:
1. Политики безопасности домена.
2. То что прокси имеет срок жизни и его нужно обновлять или указывать изначально большой.
3. Блокировки от выгрузки домена когда в домене исполняется код.
4. Проброс исключенией возникших в домене, в управляющий домен.
и т.д.

[lam0x86]

Петр:
Про пункты 1 и 3: разумеется, подход с AppDomain-ом не следует использовать в небезопасном окружении. Для таких случаев лучше использовать sandboxing в отдельном процессе. О том, что AppDomain'ы не предназначены для изоляции потенциально вредоносного кода, много раз писали разработчики .NET-а. Впрочем, подстраховаться от Environment.Exit() никогда не помешает.
В остальном согласен.

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

[Петр]

lam0x86: Так приведите примеры таких готовых решений для Макс Максимов

[lam0x86]

Последний раз сталкивался с подобной проблемой лет 5-6 назад, так что, возможно, прогресс шагнул далеко вперед. Из того, что использовал - вот: https://msdn.microsoft.com/en-us/library/bb384200(...

[Макс Максимов]

Не знаю, как переформулировать. Если вообще по-простому: сервис стоит на ASP.NET WebAPI. Просто принимает куча данных, записывает их в базу, сортирует и рассылает по определённым клиентам. Типа, пришли стандартные данные с 10 полями, он их поделил каждые к определённому клиенты и отправляет. И каждому клиенту надо в определённом виде отправлять: кому-то нужно из 10 полей только 4 поля, да ещё в POST запросе, через xml/xls/dba/mdf и тд.

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

[Петр]

Макс Максимов: Flow Processing вам бы тогда точно подошел. Привязали flow к стандартному (Schema ID) типу данных и клиенту. А далее микромодули:
1. Конвертер структуры - из структуры с 10 полями преобразуется в структуру с 4. Для примера на вход документ json, в качестве параметров текстовое представление нового json в виде шаблона ({ 'field1': { $.store.book[0].title } }) Json Path для путей к параметрами.
2. Конвертер документа - из Json документа в Json c полями "Тип" документа и "Данные" - сформированный xml/xls/dba/mdf в виде Base64
3. Http Sender - что делает POST запросы по указанному URL с телом из поля "Данные" (Конвертер документа) + Параметрами доп. заголовки HTTP запроса.

Микромодули все на базе интерфейса вида.

public interface IAssemblyModule
{
        /// <param name="executeParams">User Data</param>
        /// <param name="moduleSettings">User module settings</param>
        ModuleExecuteResult[] Execute(ModuleExecuteParams executeParams, Dictionary<string, object> moduleSettings, ModuleExecuteInfo moduleExecInfo);
}

Каждому реализуемому пользователем модулю обязательно атрибут

[Module("4D8CB3CE-58D9-42CA-848F-404B53C4E503",
            "3c5a4596-0b18-4125-befb-2c026250f21d", // SchemaID
        Name = "HTTP sender",
        Description = "HTTP sender",      
        ParameterInfoType = typeof(HttpSenderModuleParamInfo),
        EventInfoType = typeof(HttpSenderModuleEventInfo) )]

Что позволит вам с лекгостью получать, через Reflection все описание созданного клиентом модуля и регистрировать его у вас в системе.

[Макс Максимов]

Не найдётся ли примеров, книжек и другого обучающего материала по этой теме? Чёт на Pluralsight только по MEF курс, с AppDomain и Flow не нашёл. Спасибо!

[Петр]

Макс Максимов: Такого я не знаю. Все в основном находиться в google по запросам вида "C# AppDomain example"

Answer 2

[Дмитрий Еремин]

New Project -> Templates -> Windows -> Class library
на выходе получаете dll

А вот тут про подхват dll'ек на ходу: https://stackoverflow.com/questions/18362368/loadi...

Comments

[Макс Максимов]

Петр , а такой вариант подойдёт? В определённую папку буду ложить .dll-ки от каждого клиента. Система при рассылки будет по названию клиента из базы проверять такой же файл .dll в папке и подгружать их? Или это слишком быдланство?

[Петр]

Макс Максимов: Все зависит от ваших задач. Это рабочий вариант, но в нем не возможна горячая подмена dll. MEF - тоже рабочий вариант, но также без горячей замены.

Answer 3

[Ogoun Er]

Специально для этих целей в стандартные библиотеки входи MEF
Это намного проще чем писать свои host приложения на основе AppDomain.

Comments

[Петр]

Если будет нужна горячая замена, то MEF все равно придется в AppDomain размещать.