Обмен данными, статические переменные и каналы

Question

Обмен данными, статические переменные и каналы

1

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

Я разрабатываю приложение, которое связывает плагины с помощью MEF. Плагины (в основном формы, отображаемые как формы MDI) могут иметь несколько реализаций интерфейса, основанных на том, что им нужно/предлагают, мэйнфрейм проверяет, реализованы ли они, а затем удовлетворяет их потребности. Пока все в порядке, работает и работает.

Теперь, если вы запустите приложение, он запрашивает действительный логин (MainFrame), и если вход успешно завершен, пользователь будет сохранен в MainFrame. Теперь PluginManager, который знает обо всех доступных плагинах, передает пользователю плагин при активации.

Это работает, но это хороший подход?

Я также думал о наличии класса AppEnvironment, который использует несколько данных, таких как User, DataConn-Strings и т.д., Используя статические переменные. Приложение много использует Задачи, поэтому я обеспечил статические переменные, которые могут быть изменены во время выполнения с использованием статических объектов блокировки.

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

Еще одна вещь, которую я выяснил, это то, что я мог бы использовать каналы для обмена информацией между MainFrame и его дочерними формами... Разве это немного передозировано? Вам нравится/использовать трубы для таких требований?

Не поймите меня неправильно, я не ищу простой способ архивирования, что я хочу, но мне очень нравится иметь прекрасный, элегантный способ поделиться информацией в MainFrame и его дочерних формах. Если я смогу узнать что-то новое, еще лучше;)

Спасибо за внимание, любая помощь любезно оценена :)

Cheers Keil

Jsinh 23 июль 2014, в 01:17

Источник

Теги:

c#

pipe

1 ответ

Ещё вопросы

Jsinh · Accepted Answer · 2014-07-22T21-00-00.000Z

Вопрос: Это работает, но это хороший подход?

Ответ. Для простых сценариев это может быть достаточно.

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

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

Ответ: Нет, они не плохи, на мой взгляд, деликатные и с осторожностью обращаться с многопоточным приложением.

Блокировка переменной поможет в некоторой степени и в немногих случаях, я бы рекомендовал вам изучить класс Interlocked для принятия дополнительных мер предосторожности.

Вопрос: Еще одна вещь, которую я выяснил, это то, что я мог бы использовать каналы для обмена информацией между MainFrame и его дочерними формами... Разве это немного передозировано? Вам нравится/использовать трубы для таких требований?

Ответ: Pipes - один из самых быстрых способов общения между процессами.

Тематическое исследование: Используется служба WCF на основе труб, чтобы получать данные между двумя службами Windows, которые обрабатывают огромный запрос данных в секунду. Это были наиболее возможные варианты для двух сервисов, которые можно было говорить на одной машине с помощью WCF.

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

Подведите итог: лучшим примером для жизни можно воспользоваться Visual Studio SDK. Я бы предложил использовать какой-то общепринятый шаблон управления или обмена сообщениями. Обе стороны должны знать объекты сообщения/команды и ссылку на обработчик команд или мессенджер, который развлекает эти команды/сообщения. Управляемый канал для взаимодействия между вашим мэйнфреймом и кодом плагина будет способом продвижения вперед и по-прежнему расширяемым.