Цитата:
Сообщение от
DSPIC
Есть стандарт, принято ему следовать и не плодить антипатиерны.
Вот с этого места поподробнее. О каком стандарте идет речь? Я же неоднократно указывал, что то, что я делал по Варианту 1 - это
тоже стандарт. Стандарт, предусмотренный самим FrameWork. Просто этот подход используется нечасто из-за его не типичности (нестандартности самого подхода, а не реализации)
Ради интереса, сделайте поиск по перекрытым методам pack/unpack. Заглушки в этих методах встречаются довольно часто в разных
стандартных классах. Но! Все они имеют RunOn = calledFrom, при этом неявно предполагая, что речь будет всегда идти о запуске на стороне клиента. Т.е. нет проблемы сериализации.
Просто в данном конкретном случае "камнем преткновения" является RunOn = Server. Это как раз и есть то самое "бессмысленное и беспощадное" требование клиента, которое я
вынужден сделать. Клиента не интересует надо/не надо. У него есть свой "стандарт"
Вариант 1, описанный мной - это следование требованию клиента об установке RunOn = Server, но при этом выполняется отказ от сериализации. Еще раз подчеркиваю, отказ происходит
стандартными способами, предусмотренными самим FrameWork
-------------
Ответ на какой вопрос я хотел услышать, но так и не услышал
Чем грозит отказ от сериализации при настройке RunOn = Server? Т.е. класс запускается на сервере, а форма диалога на клиенте без создания дубликатов. Происходит прямое "общение" формы на клиенте и обслуживающего его класса на сервере.