Как разделить один код статического класса между разными приложениями

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

Я помещаю созданную dll в GAC. Однако кажется, что каждое приложение создает в памяти свой собственный объект шифрования.

Есть ли способ иметь только один экземпляр этого класса для повышения производительности и использования памяти?

Спасибо


person Esmail Amini    schedule 25.10.2013    source источник
comment
Srsly ... насколько большой след оставляют ваши процедуры шифрования? Вы подтвердили, что это проблема?   -  person Simon Whitehead    schedule 25.10.2013


Ответы (2)


Вы действительно подтвердили, что это вызывает беспокойство? Это было бы весьма удивительно.

Но нет, строго говоря, вы не можете совместно использовать экземпляр (или статический класс) между приложениями — вы даже не можете совместно использовать его для AppDomain в одном и том же приложении (в конечном итоге вы используете прокси-объект). Чтобы выполнить то, что вы хотите, вам придется использовать какую-то архитектуру клиент-сервер, что почти наверняка приведет к увеличению накладных расходов, чем сама система шифрования.

person Adam Robinson    schedule 25.10.2013

Нет, вы не можете создать единый элемент для процессов.

Вместо этого вы можете создать свой собственный процесс (например, службу Windows или демон в мире *NIX), который затем будут использовать другие. Для межпроцессного взаимодействия (RPC) существует множество методов, таких как именованные каналы, сокеты ( и более высокие прикладные протоколы, которые их используют), чтение и запись в файл...

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

person markmnl    schedule 25.10.2013