Re[2]: Как правильно реализовывать IEnumXXX в OPC-сервере?
От: KVakaMarshal Россия  
Дата: 01.05.10 19:48
Оценка:
Здравствуйте, Vi2, Вы писали:

Vi2>Я ОРС-сервера не писал, но общий ответ на вопрос "когда OPC-клиент должен сделать Release" такой: клиент должен сделать Release объекту тогда, когда его этот объект больше не интересует.


Ну, это понятно, попользовался — освободил. Вот меня и интересует, когда OPC-клиента (я говорю именно о OPC-клиенте и правилах которые регламентирует спецификация, в моем случае OPC DA2.05a) должен прекратить интересовать перечислитель. Я к тому, что возможно вообще нигде не регламентировано что должен OPC-клиент освобождать перечислитель, по схеме "получить перечислитель->прочитать данные->освободить перечислитель". Просто судя по тем чужим наброскам что у меня есть, то это именно так. У меня два пути:
1. Более простая и общая реализация всех перечислителей сервера (а их хватает), естественно с небольшой потерей производительности за счет промежуточного буферизирования. Этот вариант только для той схемы что я описал выше.
2. Более детальная реализация каждого метода интерфейсов IEnumXXX которые используются в OPC. В этом случае больше кода, но выше производительность и полная совместимость с любой схемой "жизни перечислителя".

Ясно, что алгоритмы различных перечислителей, как родных COM'овских, так и OPC'ишных в целом одинаковы. Очень компактно получается их реализовать шаблонно. Все прекрастно понимают гибкость шаблонных классов, поменял в одном месте, изменилось везде. Во втором варианте логика работы методов IEnumXXX:Skip и IEnumXXX:Next будет кардинально отличаться, за чет того что придется работать с разными "живыми данными", кому с группапи, кому с ячейками, а кому и с деревом сигналов. Шаблонным алгоритмом здесь уже не место. Просто если бы я знал что клиент как получит перечислитель сразу считает нужные данные и освободит его, то я сделал бы как в первом варианте, это проще.

Собственно поэтому мне нужен совет не столько по реализации интерфейсов не широкого мира COM, а именно узкой прослойки OPC.

Vi2>Вот и не парься, хотя можешь и попариться.


Ну вот я склоняюсь по своим соображениям и из выше сказанного что попарится надо. Но для уверенности пара советов бывалых OPC'истов мне бы не помешали.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.