Лучшие Практики? Дождаться приема или вызвать событие при получении
Прежде всего, я хотел поблагодарить сообщество. В последнее время ты меня здорово поддерживаешь ! Обычно мне даже не нужно задавать вопросы, потому что они уже есть. Теперь у меня есть проблема, которая напрямую не связана с кодом, но с самим программированием.
Я работаю с чипом FTDI и C# программирую коммуникационный протокол, в котором приложение для ПК действует как мастер (будет отправлять запросы), а также есть подчиненное устройство, которое будет отвечать на них, не сразу, может быть, пару раз. миллисекунды, но в любом случае, потребуется некоторое время. Я застрял в концептуальном / философском вопросе проектирования кода.
После отправки запроса, должен ли я сразу попросить ответ (проверяя также тайм-аут) или я должен постоянно контролировать вход (BackgroundWorker powered) и вызывать событие после получения ввода данных ? Что бы вы порекомендовали, что есть на вашем опыте. Какие факторы я должен учитывать, чтобы сделать свой выбор ?
Я никогда не изучал проектирование программного обеспечения самого программирования так что я думаю, что мне не хватает основы на этом, но это личный проект, над которым я работаю, и уверен, что я хотел бы получить некоторые отзывы/указатели на это от вас, ребята.
Спасибо !
2 ответа:
Мое предпочтительное решение в этом сценарии состояло бы в том, чтобы выдать запрос в асинхронном режиме (такой, что вы получаете вызов назад событием, которое срабатывает, когда он завершается), а также реализовать асинхронное время ожидания с использованием стандартных механизмов .Net, который вызывает вас обратно, если кажется, что ведомое устройство не отвечает. Таким образом, вы просто запускаете запрос и таймер, а затем можете продолжать выполнять дополнительную работу, не нуждаясь в каких-либо других потоках для обработки результатов.
Вы должны были бы убедиться, что параллельное время выход и поступление ответа обрабатываются чисто с помощью механизма блокировки, так что вы точно знаете, что вы тайм-аут или обрабатываете ответ.
Старайтесь избегать опроса и мониторинга ввода, если API вашего ведомого устройства не позволяет детерминировать генерацию событий ответа.
Обычно я бы работал с асинхронным подходом на низкоуровневом сайте и, возможно, поставил бы какой-то механизм синхронизации поверх этого. Вот несколько примеров подхода, если вы получаете фрагменты данных, и вам нужно собрать эти фрагменты вместе в целое сообщение.
Поэтому на низкоуровневом сайте реализуйте BackgroundWorker, который постоянно проверяет входящие данные и вызывает какое-то событие, если вы что-то получили и вложили это в событие.
Над этим кто-то слушает события входящих данных и помещает все эти (возможно) фрагменты во внутреннюю очередь. Там он проверяет, достаточно ли у него данных для полного сообщения, может быть, делает некоторую проверку ошибок и т. д. Если у него есть полное сообщение, он вызовет событие, чтобы отправить это сообщение всем слушателям.
Поверх этого поставьте еще один класс, который следит за сообщениями и реагирует на них. Этот класс, возможно, реализует некоторый механизм синхронизации, чтобы следить, если входящее сообщение совпадает с чем-то, что должно было случиться заранее.
Я думаю, что этот дизайн облегчает реакцию на данные, которые поступают, когда вы чего-то не ожидаете. И когда вам нравится выключаться, вам не нужно ждать, пока произойдет какой-либо тайм-аут (возможно, очень маленький, который использует низкоуровневый BackgroundWorker для извлечения данных из источника, который не поддерживает механизм событий).