Лучшие практики?Подождите, пока получите или поднять событие при получении

Question

Прежде всего, я хотел бы поблагодарить сообщество. Вы оказали большую поддержку в последнее время! Обычно мне даже не нужно задавать вопросы, потому что они уже есть. Теперь у меня есть проблема, которая не связана напрямую с кодом, а с самим программированием.

Я работаю с FTDI Chip и C #, программируя протокол связи, в котором приложение для ПК действует как Master (будет отправлять запросы), а также есть Slave-устройство, которое ответит на них, не сразу, возможно, пару миллисекунды, но в любом случае это займет некоторое время. Я застрял в вопросе разработки концептуального / философского кода.

После отправки запроса я должен сразу же запросить ответ (проверяя также тайм-аут) или я должен постоянно контролировать вход (включен BackgroundWorker) и вызывать событие после получения ввода данных? Что бы вы порекомендовали, что на вашем опыте. Какие факторы я должен учитывать при выборе?

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

Спасибо!

Answer 1

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

Так что на низкоуровневом сайте реализуйте BackgroundWorker, который постоянно проверяет поступающие данные и вызывает какое-то событиеесли вы что-то получили и поместили это в событие.

Над этим кто-то слушает события входящих данных и помещает все эти (возможно) фрагменты во внутреннюю очередь.Там он проверяет, достаточно ли у него данных для полного сообщения, может быть, он выполняет некоторую проверку ошибок и т. Д. Если у него есть полное сообщение, он вызовет событие для отправки этого сообщения всем слушателям.

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

Я думаю, что этот дизайн облегчает реагирование на данные, которые поступают, когда вы чего-то не ожидаете.А когда вы хотите завершить работу, вам не нужно ждать каких-либо тайм-аутов (возможно, очень маленького, который используется низкоуровневым BackgroundWorker для извлечения данных из источника, который не поддерживает механизм событий).

Answer 2

Мое предпочтительное решение в этом сценарии состояло бы в том, чтобы выдать запрос в асинхронном режиме (чтобы вы вызывали событие, которое срабатывает при его завершении), а также реализовать время ожидания асинхронности, используя стандартные механизмы .Net, которые вызываютВы вернетесь, если окажется, что раб не отвечает.Таким образом, вы просто запускаете запрос и таймер, а затем можете продолжать выполнять больше работы, не требуя каких-либо других потоков для обработки результатов.

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

Старайтесь избегать опроса и мониторинга ввода, если API вашего ведомого не позволяет детерминистически генерировать события ответа.