Всегда ли надо прописывать список переменных в pack?

[DSPIC]

Цитата:

Сообщение от DSPIC

[U]
Обоснуйте, почему вы "не хотите" сделать так?

?

[Владимир Максимов]

Цитата:

Сообщение от DSPIC

Обоснуйте, почему вы "не хотите" сделать так?

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

- Писать "лишний" код pack/unpack
- Инициализировать переменные, которые сразу после инициализации необходимо затирать (очищать) (getLast())

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

[DSPIC]

Цитата:

Сообщение от Владимир Максимов

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

- Писать "лишний" код pack/unpack
- Инициализировать переменные, которые сразу после инициализации необходимо затирать (очищать) (getLast())

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

Я расцениваю ваше обоснование так: "не хочу". Ну так и не делайте. О всех нюансах вы в курсе, ответ/совет вам таки не нужен, как я предполагал.

Вам приходилось сдавать майкрософту ISV решения? Там куда больше спорных моментов из ряда "кому это нужно", правки занимали недели. Так принято, работа не бессмысленная и не мусорная - вам за неё платят, как минимум. Есть стандарт, принято ему следовать и не плодить антипатиерны. Еще раз - сделать можно так как вам хочется, кому нужно будет - переделает, тоже за деньги

[dech]

Цитата:

Сообщение от dech

Если ты работаешь в Microsoft, то для тебя важно, чтобы все красиво вписывалось в инфраструктуру.

Цитата:

Сообщение от DSPIC

Вам приходилось сдавать майкрософту ISV решения?

Что и следовало доказать. :-)

[DSPIC]

Цитата:

Сообщение от dech

Если ты работаешь в Microsoft, то для тебя важно, чтобы все красиво вписывалось в инфраструктуру. Но если ты пашешь на клиенте, ты в принципе можешь прикинуть, стоит ли заморачиваться и делать лишнюю работу, пусть даже в 20 строк.

Цитата:

Сообщение от dech

Что и следовало доказать. :-)

Об этом и речь. Меньше контроля - меньше качества. На клиенте "не хочу, не буду", в MS "Надо". В итоге клиентсий код зачастую вызывает тошнотвоное чувство - уровня лабораторной работы по программированию 1-го курса института.

[Владимир Максимов]

Цитата:

Сообщение от DSPIC

Есть стандарт, принято ему следовать и не плодить антипатиерны.

Вот с этого места поподробнее. О каком стандарте идет речь? Я же неоднократно указывал, что то, что я делал по Варианту 1 - это тоже стандарт. Стандарт, предусмотренный самим FrameWork. Просто этот подход используется нечасто из-за его не типичности (нестандартности самого подхода, а не реализации)

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

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

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

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

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

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