Я размещаю службу WCF, где требования состоят в том, чтобы вызывался объект типа службы WCF, на который нет прямой ссылки, и на нем выполняются некоторые (общие) методы. Таким образом, тип создается с помощью отражения и AssemblyResolve: это нормально.
но потом я подумал - что мы ожидаем, что, возможно, 50-100 этих сборок / типов прибудут, особенно когда мы их версии. по-видимому, это должно привести к переполнению (по-прежнему теории, а не практики) памяти и производительности приложения хоста службы, поскольку все эти сборки упоминаются в mem.
так что тогда мы должны выгрузить: но единственный способ сделать это - через домен приложения. Идея состоит в том, что каждая сборка каким-то образом запускается в своем собственном домене приложения, а служба WCF фактически просто передает сообщения соответствующему домену приложения. Если домен приложения не используется для some_period_of_time, мы просто выгружаем домен приложения.
Я, вероятно, получу оценку за это, но некоторые советы будут полезны:
- это безумная идея?
- должен ли процесс работать нормально с ~ 100 сборками в памяти?
- связь с доменами приложений, вероятно, будет стоить дорого (через удаленное взаимодействие / именованные каналы): это лишает возможности идеи?
- создание домена приложения для обслуживания одного типа .dll потребует большого количества доменов приложений, это отсталый?
У меня нет опыта в этой области. Меня беспокоит размер и производительность приложения, если я не сделаю что-то подобное. однако с идеей домена приложения это в основном звучит как чрезмерное чрезмерное проектирование. я не могу изменить требование о размещении этого неизвестного .dlls.
Полагаю, мой общий вопрос:
Является ли эта идея настолько идиотской, насколько это звучит, и с чем связаны "за" и "против"?