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

[DSPIC]

Цитата:

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

Возможно, я что-то пропустил. Дайте, пожалуйста, ссылку на обоснование. Т.е. где указаны причины по которым надо делать так, а не иначе. Ну, или просто процитируйте.

По факту, я и пытаюсь получить обоснованный и аргументированный ответ на правильно понятый Вами вопрос.

А КАК нужно-то? Точнее, не столько даже "как", сколько "почему именно ТАК"?

Как нужно:
- паковать перменные в pack\unpack, использовать их в диалоге
- написать конструктор, с getLast() и перетереть сохраненные значение переменных, если предыдущее значение какой-то переменной

Обоснование
- поддержав сериализацию, вы не нарушаете правил RunBase Framework и следуете BestPractice
- класс сможет выполняться на сервере, в Batch даже если вам этого пока не нужно (может другим понадобится)
- вы полностью сохраняете универсальность класса, задавая нужное вам поведение отдельным конструктором.

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

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

Цитата:

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

Обоснование
- поддержав сериализацию, вы не нарушаете правил RunBase Framework и следуете BestPractice

- Отказ от поддержки сериализации НЕ нарушает правила RunBase FrameWork. Это один их штатных, предусмотренный самим FrameWork, способ реализации
- В Best Practices я не встречал упоминания об обязательности перекрытия pack/unpack. Ну, кроме обязательности перекрытия абстрактных методов из-за чего и возникает необходимость в заглушке. Но к Best Practices это не относится

Цитата:

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

- класс сможет выполняться на сервере, в Batch даже если вам этого пока не нужно (может другим понадобится)

- Класс и так выполняется на сервере. Это было в постановке задачи. RunOn = Server
- Batch не нужен и не понадобиться. Это также было в постановке задачи

Если Batch все-таки понадобиться, то объем модификаций при использовании заглушек и при затирании кеша будет сопоставим. Надо будет организовать "вырезание" из кеша тех переменных, которые не надо сохранять от тех, которые понадобятся для работы Batch. Там придется добавлять ряд переменных именно для Batch

Цитата:

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

- вы полностью сохраняете универсальность класса, задавая нужное вам поведение отдельным конструктором.

- Не понял этого тезиса. О чем идет речь?

[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? Т.е. класс запускается на сервере, а форма диалога на клиенте без создания дубликатов. Происходит прямое "общение" формы на клиенте и обслуживающего его класса на сервере.