Подключение к встроенному устройству с Windows и .Net - PullRequest
2 голосов
/ 16 марта 2010

Я создаю приложение .net (xp, vista, 7), которое будет взаимодействовать со встроенным устройством. Я смогу подключиться через IP, последовательный порт и модем. Вопрос: Должен ли я разрешить какой-либо тип открытого соединения в моем приложении, которое позволит мне подключаться к устройству через некоторые другие каналы, которые могут быть установлены в операционной системе, просто чтобы обеспечить возможность расширения в будущем без необходимости что-либо менять на устройстве? Я просто представлял, что операционная система сможет обслуживать все каналы связи, которые могут быть установлены через операционную систему для устройства. Вроде бы админ настроил какой-нибудь канал через SMTP или другой протокол. Я просто не хотел ограничивать себя и игнорировать более открытую архитектуру.

Спасибо.

Ответы [ 3 ]

2 голосов
/ 16 марта 2010

Я бы сказал: Нет.

Причина 1: не создавайте ненужные вам функции.

Причина 2: если другой системе необходим доступ, она может использовать TCP или последовательный порт через сплиттер. Не уверен, что это возможно с модемом. Подобную функциональность было бы довольно сложно реализовать и реализовать самостоятельно.

0 голосов
/ 17 марта 2010

Меня тоже смущает вопрос; Вы можете быть более точным (и кратким)?

Один комментарий, который я хотел бы сделать, заключается в том, что вы могли бы рассмотреть реализацию PPP на последовательных портах / модемных каналах, чтобы TCP / IP использовался повсеместно и позволял множественные соединения через все каналы.

0 голосов
/ 16 марта 2010

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

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

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

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

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

...