Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Нужен совет по проектированию  (Прочитано 10272 раз)
0 Пользователей и 1 Гость смотрят эту тему.
xelos
Гость
« : 13-01-2005 15:19 » 

в общем есть прога с использованием FrameWork 1.1. Эта прога будет общаться с внешним девайсом по MODBUS (физический протокол - RS232). Поскольку в FrameWork 1.1  нету поддержки последовательного порта - пришлось написать класс-обертку над апишными функциями (вынесено в отдельную) - что означает, что теряем независимость от ОС. Судя по анонсам, в FrameWork 2.0 будет реализована поддержка последовательного порта. Следовательно, в будущем хотелось бы, чтобы программа работала с родными функциями, а не через апи. Как организовать, чтобы в будущем переход с класса-обертки на родные функции был бы как можно безболезненней. На ум приходит техника COM - основная программа обращается через интерфейсы к реализации (т.е. в будущем можно подменить библиотеку реализации). Почитав статьи про COM в .NET возникают вопросы по поводу сосуществования двух технологий... Или может я вообще голову не тем, чем надо забиваю? Если в будущем я перепишу класс последовательного порта с родными функциями - можно ли сейчас предусмотреть возможность его подключения?
Записан
npak
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #1 : 13-01-2005 15:33 » 

Xelos

У тебя сейчас есть класс, который работает с СОМ портом через WinAPI, так?  И ты хочешь, что бы при переходе на Framework 2.0 тот код, которых пользуется существующим классом, не пострадал?

Для этого после выхода Framework 2 тебе надо будет переписать класс, предоставляющий доступ к СОМ порту.  Оставить интерфейс, но в методах вызовы WinAPI заменить на вызовы методов .NET классов из нового Framework'а

Все изменения будут локализованы в одном месте, и код пользователей (теоретически) ничего не заметит.
« Последнее редактирование: 20-12-2007 20:33 от Алексей1153++ » Записан

UniTesK -- индустриальная технология надежного тестирования.

http://www.unitesk.com/ru/
xelos
Гость
« Ответ #2 : 13-01-2005 16:29 » 

все так.
т.е. просто предлагаешь потом переписать класс для коммуникации с девайсом, скомпилировать его в длл и на машине пользователя просто заменить длл?

не будет ли проблем, если просто заменить длл? еще свежа в памяти история создания СОМ (не порт который, а объектная модель) - который и был призван разрешить проблемы различных версий реализаций объектов.

Я вот думаю, если FrameWork 2.0 будет работать по-другому с объектами (по другому память выделять или еще что...), не повторится ли история с dll-hell? может стоить оформить класс что-нибудь типа ActiveX компонента (через библиотеку контролов) и следующую версию тоже как ActiveX компонент - благо это все поддерживается .НЕТ?
Записан
npak
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #3 : 14-01-2005 08:41 » 

Да, я предлагаю после выхода Framework подменить библиотеку с классами для доступа к порту.
Микрософт клянётся и божится, что классы, сделанные под Framework 1 будут грузиться и работать без изменений -- обещают полную совместимость. 

Если в новой версии будет сохранён интерфейс класса и функциональность методов, то клиентский код должен работать.
Записан

UniTesK -- индустриальная технология надежного тестирования.

http://www.unitesk.com/ru/
xelos
Гость
« Ответ #4 : 14-01-2005 09:30 » new

ок, спасибо, так и сделаю...
Записан
xelos
Гость
« Ответ #5 : 24-01-2005 08:10 » 

Еще раз пересмотрел как распространяются приложения .НЕТ и как контролируется безопасность сборок. Возникает вопрос. Микрософт пишет, что в манифесте сборки сохраняется версия сборки, ссылки на внешние сборки, и ключи идентификации (даже для внешних сборок). Получается, что для замены существующей сборки более поздней версией надо делать позднее связывание приложения и сборки, иначе CLR не запустит из моего приложения новую версию сборки, т.к. идентификационные ключи не совпадают... Иначе надо переопределять политку проверки сборок (не понятно как делается). Или я не так понял MSDN?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconassemblyversioning.asp
Записан
npak
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #6 : 24-01-2005 12:05 » 

Тогда надо заранее предусмотреть загрузку с частично заданными параметрами сборки

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconpartialassemblyreferences.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconhowruntimelocatesassemblies.asp
Записан

UniTesK -- индустриальная технология надежного тестирования.

http://www.unitesk.com/ru/
xelos
Гость
« Ответ #7 : 24-01-2005 14:20 » 

пасип, похоже то что надо... Позднее связывание сборки с приложением...
Записан
xelos
Гость
« Ответ #8 : 24-01-2005 14:33 » 

у меня в классе приложения объявлен член класса, который и осуществляет коммуникацию RS232. В случае с поздним связыванием, такое не пройдет, поскоку приложение не знает о классе... Значит порядок - объявляем переменную типа Object, объявляем переменную типа Assembly, потом через System.Reflection, потом вытаскивать классы из сборки через GetType и тип Object кастить на типы.

хм, не слишком я мудрю?
Записан
xelos
Гость
« Ответ #9 : 25-01-2005 10:02 » 

в общем проблему с версиями можно решить через конфигурационный файл приложения... некрасивое, однако, решение...
Записан
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines