Показать сообщение отдельно
Старый 24.04.2021, 16:17   #54  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Нажмите на изображение для увеличения
Название: 1.PNG
Просмотров: 29
Размер:	95.6 Кб
ID:	13162

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Ну как же... а это о чем?
Может, я читаю как-то через слово, но вот написано: "коллекция типизированных объектов". В моем понимании типизированные объекты - это в оперативной памяти.
типизированные объекты не обязаны появляться в оперативной памти сразу


gl00mie, у меня просьба - можешь перейти от фазы критики постановки задачи к фазе генерации решения?

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

======================
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Данные - могут храниться в таблице, а вот типизированные объекты (коллекцию которых предполагалось создать в рамках идеального решения) - не могут, потому что в таблице могут храниться лишь сериализованные представления объектов. А еще WCF (сюрприз!) не умеет читать данные из таблицы СУБД.
Или сообщение про "идеальное решение" с коллекцией типизированных объектов читать не надо было, потому что оно противоречит исходному сообщению про таблицы и контейнеры?
поэтому я и ввел фазу подготовки данных.
обрати внимание не генерация данных

Цитата:
Сообщение от gl00mie Посмотреть сообщение
См. как работают с ними в 12-ке локализаторы, когда генерят документы через OpenXML. В синтаксисе X++ поддержки нет, а работать с ними в Аксапте можно.
вот как раз этот антипаттерн я отметаю сразу
и сразу спрашиваю - накладные расходы на выполнение "этого" X++ точно будут меньше, чем накладные расходы на передачу элементов по одному?

gl00mie, участники, заклинаю!
тема НЕ называется как можно передать...!
тема называется как правильно передать!

пожалуйста!


Цитата:
Сообщение от gl00mie Посмотреть сообщение
Я лично не вижу, почему накладные расходы на работу с таким .NET-овским DTO должны быть выше, чем накладные расходы на работу с каким-нить CLRObject в X++.
X++ тупо медленный.
чем больше кода на X++, тем медленнее он будет выполняться относительно CLR

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

ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?


Цитата:
Сообщение от gl00mie Посмотреть сообщение
Когда речь идет о том, чтобы передавать данные между двумя ERP-системами, то мне лично странно слышать постановку задачи вида "передать 100500 элементов" в отрыве от того, как они будут обработаны на принимающей стороне, если там п/редполагается какая-то валидация и обработка этих данных.
во-первых, кто тебе сказал, что постановка задачи идет "в отрыве"? и кто тебе сказал, что вопрос этой темы - это полная постановка задачи?

во-вторых, кто тебе мешает ввести в обсуждение те аспекты, которые ты считаешь обязательными и рассказать "как правильно передать" с учетом этих аспектов?

Цитата:
Сообщение от gl00mie Посмотреть сообщение
то как раз и возникают решения, начиная с использования брокера сообщений и заканчивая (о, нет!) реализацией view на стороне отправителя с возможностью принимающей стороне читать этот view по мере возможности.
да-да-да... ну же, не томи, расскажи как правильно то?
особенно "передать" "вьюшкой".

просто расскажи как правильно.

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Через веб-сервис что ли? В один поток успеет ли интеграция всё передать в приемлемое время? А если в несколько потоков, то во сколько?
а что об этом сказано в вопросе? ничего?
что это значит? что ты можеешь использовать допущения, которые тебе нравятся.
и рассказать "как правильно передать" в рамках этих допущений.

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

расскажи.

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Есть ли зависимости между разными элементами коллекции, влияющие на порядок передачи, или они все могут передаваться в произвольном порядке?
шикардос вопрос!
зависимости конечно есть, как между таблицами (шапка-строки), так и между записями в одной таблице (всякие деревья с id/parentId)

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

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

Цитата:
Сообщение от gl00mie Посмотреть сообщение
И чем определение количества потоков будет лучше, скажем, ручной нарезки на пакеты?
да! расскажи пожалуйста.

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Можно до опупения поливать грязью варианты, которые не нравятся, придумывая какие-то крайности, которые непонятно, что доказывают. Но, к примеру, майкрософтовская команда Dynamics AX 2012, занимающаяся финансами, поставила себе задачу разнести 100000 журналов ГК - и решила ее, минимизировав накладные расходы пакетной инфраструктуры за счет нарезки журналов на такие вот "чанки", а потом встроила это решение в стандарт.
я уже говорил, что такое решение должно слишком много знать о транспортном уровне. по сути такое решение означает написать транспортный уровень самостоятельно.

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Намного ли эта майкрософтовская команда глупее mazzy, пытающегося пропихнуть 100500 элементов коллекции через WCF? Не думаю...
я там был. намного. я это знаю. к сожалению.

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Ну конечно же, когда системы дергают друг дружку через кастомные AIF-сервисы, это они ничего друг о друге не знают, а вот если дергать штатный Query Service, то это "слишком много знать о внутреннем устройске друг-друга". Вы не понимаете, это другое (с)
мне кажется, что сейчас ты чушь сморозил. но вполне допускаю, что это я чего не понял.
можешь пояснить?
__________________
полезное на axForum, github, vk, coub.