VB.NET Асинхронный анализ последовательных данных, получение данных из разделяемой функции в экземпляры

Question

VB.NET 2010, .NET 4

Здравствуйте,

Я некоторое время боролся с логикой этого и надеялся на небольшое понимание.

Я работаю над приложением для управления промышленной машиной, состоящей из множества устройств, подключенных к компьютеру. Большинство, если это разумно, но у меня проблемы с устройствами RS-232. Одним из устройств RS-232 является необычный источник питания с множеством функций. На данный момент важны считывание напряжения, запись напряжения, считывание тока и запись тока.

Шаблон проектирования, который я пытаюсь реализовать, представляет собой шаблон, в котором каждое подключенное устройство представлено объектом, имеющим методы для чтения / записи и т. Д., И свойствами для таких вещей, как COM-порт и т. Д.

Для этого источника питания, очевидно, ссылка на порт должна быть общей для экземпляров, поэтому у меня есть базовый класс (скажем, PowerSupply) с портом защищенного общего свойства как IO.Ports.SerialPort. Затем у меня есть пара классов, которые наследуются от этого класса, PowerSupplyVoltage и PowerSupplyCurrent, каждый из которых определяет методы и свойства чтения / записи для хранения последних значений чтения / записи.

Моя проблема заключается в анализе ответа от источника питания с использованием события Port.DataRectained в общем объекте SerialPort. Протокол, используемый источником питания, указывает, какие данные он отправляет в каждом ответном пакете. Таким образом, в основном, это может сказать что-то эквивалентное «Напряжение 100 В» или «Ток 1 А» или «Напряжение установлено в 150 В» и т. Д.

Я пытаюсь разобрать это в общей функции. Только в процессе анализа я могу определить, какое значение экземпляра для чтения / записи нужно обновить. Я не могу получить доступ к свойствам чтения / записи значений экземпляров из общей функции. Мой мозг болит от попыток думать, как сделать это правильно. Лучшее, о чем я могу подумать, - это создать какой-нибудь объект PowerSupplyCommunicator, который будет поддерживать ссылки на экземпляры PowerSupplyVoltage и PowerSupplyCurrent вместе с общими функциями Port и DataReceveHandler. Это выглядит довольно глупо, хотя. Есть какие-нибудь мысли по поводу умного пути по этому поводу?

Большое спасибо заранее, Brian

Answer 1

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

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

Третий вариант заключается в том, чтобы экземпляры объекта поддерживали один или несколько интерфейсов, таких как INotifyVoltageChanged, INotifyCurrentChanged и т. Д., И вызывали некоторый метод в общем объекте для регистрации самих себя.

Важно, однако, при использовании любого из этих подходов отметить, что если один из отдельных экземпляров объекта будет оставлен, общий объект, скорее всего, навсегда сохранит ссылку на него. Если используется подход № 3, общий объект может содержать WeakReference к объекту, а не обычную («сильную») ссылку. Это немного замедлит обработку уведомлений об обновлении, но исключит риск того, что заброшенный объект будет жить вечно. Конечно, отдельные экземпляры объекта должны реализовывать IDisposable и должны отписываться от любых уведомлений при удалении, но если не используются слабые ссылки, императив, который фактически должен вызываться Dispose, сильнее, чем у многих других типов объектов. Обратите внимание, что если не используются слабые ссылки, Финализатор будет бесполезным.