ax3,ax4,ax2009,ax2012: Есть ли красивый способ передать packable объект между клиентом и сервером?

[belugin]

Возможно Маззи практикует Ax-буддизм и это коаны:

Ученик, получивший коан от мастера, пытается решить коан всеми возможными способами и «подключает» все больше и больше сил для решения логически неразрешимой проблемы. В результате, когда «отключаются» все пять чувств, ученик находится на стадии, которую в йоге именуют дхарана. В этом состоянии коан и ученик остаются один на один (плюс некоторое блуждание ума). Если ум ученика достаточно «зрелый», то однажды блуждания ума затихают и остается лишь коан. В этот момент коан и ученик — целое, ученик испытывает проблеск реальности, известный как просветление или сатори.

Хлопок одной ладонью, клиентский код в пакетном задании, передача объекта туда где он уже есть (обратно на клиента).

[mazzy]

Цитата:

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

Ученик, получивший коан от мастера...Хлопок одной ладонью, клиентский код в пакетном задании, передача объекта туда где он уже есть (обратно на клиента).

Как странно ты воспринимаешь реальность. Ну, ок.

Цитата:

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

Все же у любого зрелого программиста есть восприятие вторичных программистских признаков.

У зрелого есть не только восприятие, но и способность задавать вопросы.

Всем,
Меня искренне прикалывает, как вместо обсуждения технического вопроса, участники пытаются обсуждать автора вопроса.
Повторюсь, что давным-давно этим страдали 1Сники.
https://coub.com/view/1s5rp

Цитата:

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

Красиво это xSysLastValue::saveLast(this) и xSysLastValue::getLast(). Страшная такая но суровая красота

Согласен, что такой способ есть.
Но чтобы красиво использовать SaleLast c this, нужно переопределить четыре метода (или предоставить четыре параметра).
SaveLast записывает данные в контейнер, следовательно никаких индексов по содержимому. А также ограничение на размер сохраняемых данных (сложности с передачей больших контейнеров).

SaveLast записывает контейнер с данными как одно memo-поле, которое в SQL не пришей кобыле хвост. А можно записывать каждое значение контейнера как отдельную запись в SQL, все записи одного SaveLAst должны получить некий идентификатор сессии. Так можно получить поиск по содержимому.

это что касается SaveLast.
Возвращаясь к теме передачи объекта между клиентом и сервером...

Как уже упоминал некий ax_mct ранее, можно записывать данные в отдельную таблицу. Можно ли запись в отдельную таблицу сделать более элегантной, нежели четыре метода для SaveLast?

Можно разбивать packable контейнер на куски. Чтобы обойти ограничение на размер и уменьшить относительные накладные расходы на обслуживание клиент-серверного пакета. Можно пообсуждать за минимизацию относительного оверхеда.

Я удивлен, но не увидел обсуждения стандартных классов по передаче файлов между клиентом и сервером SysFileDeploy, AifWebReferenceUtil (второй умеет как с клиента на сервер, так и с сервера на клиент). Отлично понимаю, что способ передачи файла - не идеал. Но красоту поискать можно. Можно и посравнивать с другими способами.



как способ взаимодействия между клиентАМИ и серверАМИ можно рассмотреть запись в AOT\resource.

Но если честно, то я скорее ожидал увидеть развитие темы в сторону клиентских и серверных кэшей. И ограничения этих способов.

может еще есть какие способы?
а какой из них самый красивый? в том смысле, что нравится вам?

=================
А да, и mazzy обсуждать тоже можно, и о том что runbase уже есть, как и о принципиально-философской неразрешимости данного технического вопроса.
Это прикольно.

[axm2017]

Цитата:

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

..У зрелого есть не только восприятие, но и способность задавать вопросы.
.

Ок. Так чем вас не устраивает стандарт в виде RunBase и ко?

[mazzy]

Цитата:

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

Ок. Так чем вас не устраивает стандарт в виде RunBase и ко?

почему вы считаете, что он меня не устраивает?

[axm2017]

Цитата:

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

почему вы считаете, что он меня не устраивает?

Если устраивает то и вопроса по сути нет. Работайте с ним он есть во всех версиях и стандартен.

[mazzy]

Цитата:

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

Если устраивает то и вопроса по сути нет. Работайте с ним он есть во всех версиях и стандартен.

Есть, сэр! Разрешите продолжать работу с ним?

Для тех, кто знает, что передача объекта между клиентом и сервером может быть вне "сценария" пользователь запустил некую обработку
и понимает различие между использованием понятия и самим понятием, повторю вопрос:

Цитата:

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

вопрос по ax3,ax4,ax2009,ax2012

предположим, у нас есть объект с правильно реализованным интерфейсом SysPackable (есть правильные pack/unpack)

Сейчас, чтобы передать объект с клиента на сервер и обратно, приходится подпрыгивать с методами newOnServer, newOnClient, вручную проверять ObjectOnServer, вызывать pack/unpack и прочие некрасивости.

Есть ли красивый способ передать packable объект между клиентом и сервером?

[gl00mie]

Цитата:

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

чтобы красиво использовать SaleLast c this, нужно переопределить четыре метода (или предоставить четыре параметра).

В исходной постановке ведь говорится про объект packable, а не про this - для packable можно сделать вспомогательный класс, который будет реализовывать нужные методы SysSaveable, а на вход получать некий идентификатор плюс SysPackable-объект, который уже собственно паковать либо распаковывать вместо себя. Не знаю, правда, насколько такая реализация будет считаться "красивой".

Цитата:

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

SaveLast записывает данные в контейнер, следовательно никаких индексов по содержимому. А также ограничение на размер сохраняемых данных (сложности с передачей больших контейнеров).
SaveLast записывает контейнер с данными как одно memo-поле, которое в SQL не пришей кобыле хвост. А можно записывать каждое значение контейнера как отдельную запись в SQL, все записи одного SaveLAst должны получить некий идентификатор сессии. Так можно получить поиск по содержимому.

Ну вот, начали с клиент-серверной передачи объектов, а пришли к поиску по содержимому объектов в базе SQL Напомнило один анекдот:

Цитата:

- Слушай, ты разработчик. Ответь, почему разработчики всегда неправильно оценивают время на создание программ?
- Представь что тебе надо разгрузить машину, сколько времени это займет?
- Пару часов
- Это камаз
- 8 часов
- Камаз, груженый песком
- 12 часов
- У тебя нет лопаты и инструментов, только твои руки
- 2 дня
- На улице -40
- 4 дня
- Камаз вообще под водой
- Так же нечестно, ты постоянно придумываешь новые условия! К чему ты мне вообще все это рассказываешь? Вы, разработчики, вечно всякую фигню рассказываете! Вместо этого могли бы просто оценить правильное время на разработку.

Цитата:

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

Я удивлен, но не увидел обсуждения стандартных классов по передаче файлов между клиентом и сервером SysFileDeploy

У меня лично был весьма негативный опыт его использования

Цитата:

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

AifWebReferenceUtil (второй умеет как с клиента на сервер, так и с сервера на клиент).

А он точно был в версиях "ax3,ax4", которые упоминаются в исходном вопросе?

Цитата:

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

как способ взаимодействия между клиентАМИ и серверАМИ можно рассмотреть запись в AOT\resource.

Это те ресурсы, которых не было в старых версиях, а в ax2012 они - свои на каждом АОСе с его локальным CIL, да? И вообще, писать в приложение (design-time) что-либо для каждодневной работы конкретной инсталляции (runtime) - это моветон, как по мне. Тем более в последних версиях и не осуществимый.

Цитата:

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

если честно, то я скорее ожидал увидеть развитие темы в сторону клиентских и серверных кэшей. И ограничения этих способов.

Т.е. в одном случае предлагается резать контейнер на части, чтобы обойти ограничение на размер пакета в ax4/ax2009/ax2012, а в другом случае предлагается просто закрыть глазки ладошками и представить, что этих ограничений нет? Пускай, мол, среда времени выполнения абстрагирует нас на вставке в кэш на другой стороне от того, что есть какие-то там RPC и какие-то там maxbuffersize в настройках...

Цитата:

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

Отлично понимаю, что способ передачи файла - не идеал. Но красоту поискать можно. Можно и посравнивать с другими способами.

Такое ощущение, что вместо решения практической задачи идет составление опросника для собеседования. Как там у Джоэла Спольски?

Цитата:

Каким бы превосходным C++ кодировщиком ни был человек без опыта в API, он знает только около 10% того, что он должен использовать каждый день для написания кода запускаемого на API. Когда дела в экономике идут хорошо, это не имеет значения. Вы все еще имеете работу и наниматели платят стоимость вашего обучения соответствующей платформе. Но когда в экономике царит неразбериха и 600 человек подают заявления на каждую открытую вакансию, наниматели могут позволить себе удовольствие выбирать программистов которые уже эксперты в интересующей их области. Например, программистов, которые могут назвать четыре способа заслать файл по FPT из кода на Visual Basic и слабые и сильные стороны каждого из них.

[mazzy]

Цитата:

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

В исходной постановке ведь говорится про объект packable, а не про this

правильно говоришь. про SysLastValue заговорил ax_mct
совершенно верно, в исходной формулировке не было.

Цитата:

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

- для packable можно сделать вспомогательный класс, который будет реализовывать нужные методы SysSaveable, а на вход получать некий идентификатор плюс SysPackable-объект, который уже собственно паковать либо распаковывать вместо себя.

а распаковщик откуда узнает этот идентификатор? распаковщик на другой стороне.
раз уж все равно передавать надо между клиентом и сервером, то может лучше передавать не идентификатор, а сам объект?

Цитата:

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

Не знаю, правда, насколько такая реализация будет считаться "красивой".

Я тоже.

Цитата:

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

Ну вот, начали с клиент-серверной передачи объектов, а пришли к поиску по содержимому объектов в базе SQL Напомнило один анекдот:

gl00mie, даю маячок: про SysLastValue заговорил ax_mct.
мой исходный вопрос повторить?

Цитата:

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

У меня лично был весьма негативный опыт его использования

это не значит, что подход, примененный в этом классе нельзя рассматривать для решения исходного вопроса.

Цитата:

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

А он точно был в версиях "ax3,ax4", которые упоминаются в исходном вопросе?

нет. это не значит, что подход, примененный в этом классе нельзя рассматривать для решения исходного вопроса.

Цитата:

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

Это те ресурсы, которых не было в старых версиях, а в ax2012 они - свои на каждом АОСе с его локальным CIL, да?

ага. но они могут быть синхронизированы. почему бы не рассмотреть и этот вариант и отметить плюсы и минусы.

Цитата:

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

И вообще, писать в приложение (design-time) что-либо для каждодневной работы конкретной инсталляции (runtime) - это моветон, как по мне. Тем более в последних версиях и не осуществимый.

отличное рассуждение в ветке про "красивый способ".
майкрософту бы в уши.

Цитата:

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

Т.е. в одном случае предлагается резать контейнер на части, чтобы обойти ограничение на размер пакета в ax4/ax2009/ax2012, а в другом случае предлагается просто закрыть глазки ладошками и представить, что этих ограничений нет? Пускай, мол, среда времени выполнения абстрагирует нас на вставке в кэш на другой стороне от того, что есть какие-то там RPC и какие-то там maxbuffersize в настройках...

gl00mie, ты опять не понял.
я не предлагаю способы к реалзации.
я предлагаю рассмотреть различные способы и обсудить плюсы-минусы-красоту.
исходный вопрос повторить?

Цитата:

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

Такое ощущение, что вместо решения практической задачи

а вот это совершенно в точку.
у меня нет проблем с решением практических задач.
мне хотелось бы обсудить, услышать что думаю другие по данной теме, возможно, узнать что-то новое.
собственно для этого публичный форум и нужен

Цитата:

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

идет составление опросника для собеседования. Как там у Джоэла Спольски?

господи... с составлением опросника у меня тоже проблем нет.