Показать сообщение отдельно
Старый 19.12.2016, 14:56   #6  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,713 / 1201 (44) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от DSPIC Посмотреть сообщение
Есть стандарт, принято ему следовать и не плодить антипатиерны.
Вот с этого места поподробнее. О каком стандарте идет речь? Я же неоднократно указывал, что то, что я делал по Варианту 1 - это тоже стандарт. Стандарт, предусмотренный самим FrameWork. Просто этот подход используется нечасто из-за его не типичности (нестандартности самого подхода, а не реализации)

Ради интереса, сделайте поиск по перекрытым методам pack/unpack. Заглушки в этих методах встречаются довольно часто в разных стандартных классах. Но! Все они имеют RunOn = calledFrom, при этом неявно предполагая, что речь будет всегда идти о запуске на стороне клиента. Т.е. нет проблемы сериализации.

Просто в данном конкретном случае "камнем преткновения" является RunOn = Server. Это как раз и есть то самое "бессмысленное и беспощадное" требование клиента, которое я вынужден сделать. Клиента не интересует надо/не надо. У него есть свой "стандарт"

Вариант 1, описанный мной - это следование требованию клиента об установке RunOn = Server, но при этом выполняется отказ от сериализации. Еще раз подчеркиваю, отказ происходит стандартными способами, предусмотренными самим FrameWork

-------------

Ответ на какой вопрос я хотел услышать, но так и не услышал

Чем грозит отказ от сериализации при настройке RunOn = Server? Т.е. класс запускается на сервере, а форма диалога на клиенте без создания дубликатов. Происходит прямое "общение" формы на клиенте и обслуживающего его класса на сервере.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...

Последний раз редактировалось Владимир Максимов; 19.12.2016 в 15:02.