Цитата:
Сообщение от
mazzy
Цитата:
Сообщение от
gl00mie
прямо вот всю коллекцию сразу?
а что об этом сказано в моем утверждении? правильно - ничего.
Ну как же... а это о чем?
Цитата:
Сообщение от
mazzy
давайте я таки скажу какое решение я бы считал идеальным:
1. отправитель готовит коллекцию типизированных объектов произвольного размера
2. отправитель вызывает какой-нибудь специальный метод
3. транспортный уровень сам организует поток (stream), сам разбивает на пачки, сам собирает эти пачки на приемнике
4. приемник получает собранную коллекцию типизированных объектов
Может, я читаю как-то через слово, но вот написано: "коллекция типизированных объектов". В моем понимании типизированные объекты - это в оперативной памяти.
Цитата:
Сообщение от
mazzy
в аксапте (сюрприз!) данные могут хранится в таблице!
Данные - могут храниться в таблице, а вот типизированные объекты (коллекцию которых предполагалось создать в рамках идеального решения) - не могут, потому что в таблице могут храниться лишь
сериализованные представления объектов. А еще WCF (сюрприз!) не умеет читать данные из таблицы СУБД.
Или сообщение про "идеальное решение" с коллекцией типизированных объектов читать не надо было, потому что оно противоречит исходному сообщению про таблицы и контейнеры?
Цитата:
Сообщение от
mazzy
И как это сделать из Аксапты? В которой нет генериков.
См. как работают с ними в 12-ке локализаторы, когда генерят документы через OpenXML. В синтаксисе X++ поддержки нет, а работать с ними в Аксапте можно.
Цитата:
Сообщение от
mazzy
делать wrapper-объект? накладные расходы на работу wrapper-объекта точно будут меньше, чем накладные расходы при передаче элемента по одному?
В WCF для передачи другой стороне нужно использовать сериализуемые объекты. Если таким объектом будет .NET-овский data transfer object, специально созданный нами в отдельной сборке, то мы при этом будем иметь возможность создать IEnumerable<> для этого .NET-овского DTO, причем создать из X++. Я лично не вижу, почему накладные расходы на работу с таким .NET-овским DTO должны быть выше, чем накладные расходы на работу с каким-нить CLRObject в X++.
Цитата:
Сообщение от
mazzy
Насколько я понимаю, выбор брокера НИКАК не влияет на рассуждения о том, как правильно передавать 100500 элементов коллекции.
Если вы считаете не так, то просто скажите "1. используем вот это 2. это не буфер ограниченного размера и не поток. 3. и это будет правильно потому-то"
Когда речь идет о том, чтобы передавать данные между двумя ERP-системами, то мне лично странно слышать постановку задачи вида "передать 100500 элементов" в отрыве от того, как они будут обработаны на принимающей стороне, если там предполагается какая-то валидация и обработка этих данных. А если рассматривать задачу в комплексе (а не просто "вот у меня 10 пивных банок башенкой стоят ровно, как мне поставить 1000 пивных банок, чтоб не падали?"), то как раз и возникают решения, начиная с использования брокера сообщений и заканчивая (о, нет!) реализацией view на стороне отправителя с возможностью принимающей стороне читать этот view по мере возможности.
Цитата:
Сообщение от
mazzy
Чтобы подвести некоторый итог, давайте перечислю варианты, которые здесь прозвучали:
1. Передавать элементы по одному и не парится - в конечном итоге это может быть и не так уж накладно.
Через веб-сервис что ли? В один поток успеет ли интеграция всё передать в приемлемое время? А если в несколько потоков, то во сколько? Есть ли зависимости между разными элементами коллекции, влияющие на порядок передачи, или они все могут передаваться в произвольном порядке? И чем определение количества потоков будет лучше, скажем, ручной нарезки на пакеты?
Цитата:
Сообщение от
mazzy
2. Вручную создавать пакеты (chunks) с некоторым ограниченным числом элементов
можно до опупения добавлять искусственного интеллекта в автоопределение отптимального числа элементов в чанке.
Можно до опупения поливать грязью варианты, которые не нравятся, придумывая какие-то крайности, которые непонятно, что доказывают. Но, к примеру, майкрософтовская команда Dynamics AX 2012, занимающаяся финансами, поставила себе задачу разнести 100000 журналов ГК - и решила ее, минимизировав накладные расходы пакетной инфраструктуры за счет нарезки журналов на такие вот "чанки", а потом встроила это решение в стандарт. Намного ли эта майкрософтовская команда глупее
mazzy, пытающегося пропихнуть 100500 элементов коллекции через WCF? Не думаю...
Цитата:
Сообщение от
mazzy
в граничном случае супер-интеллекта придется кодить транспортный уровень вручную. и не факт, что в этом случае накладные расходы получатся меньше, чем при передаче элементов по одному
[...]
5. магические внешние брокеры, которые по мнению авторов несомненно решат все проблемы, но ни один из авторов не сказал как именно решат.
Опять крайности, которые должны доказать непонятно что? Где были утверждения о том, что брокеры - магические и что они решат все проблемы?..
Цитата:
Сообщение от
mazzy
6. некоторые самые смелые говорят, что для WCF в настройках app.config можно увеличить размер буфера (вместо 65Кб поставить 100Мб, например).
Это вот как раз "10-метровые пивные банки"
Цитата:
Сообщение от
mazzy
7. очень нетрадиционный, но очень привлекательный способ -
воспользоваться сервисом Query Service
это не совсем то, о чем спрашивалось. и разные системы должны слишком много знать о внутреннем устройстве друг-друга.
Ну конечно же, когда системы дергают друг дружку через кастомные AIF-сервисы, это они ничего друг о друге не знают, а вот если дергать штатный Query Service, то это "слишком много знать о внутреннем устройске друг-друга". Вы не понимаете, это другое (с)
Цитата:
Сообщение от
mazzy
9. и как же я забыл! ПДБ - промежуточная база данных. как частный случай middleware.
Да тю!.. В топку эти ПБД - писать уже сразу в чужую базу, в какую-нить промежуточную таблицу, и дело с концом, всё равно ведь обе системы в одном домене. Накладных расходов почти никаких, скорость максимальная, сплошной профит...
Цитата:
Сообщение от
mazzy
Ну отлегло, а то я уже подумал, что это все превращается в бесконечную игру
"Почему бы вам не?.. Да, но..."
Цитата:
ПБВНДН может разыгрываться любым числом участников. Действующий предлагает задачу. Другие начинают предлагать решения, каждое из которых начинается словами: «А почему бы вам не...» На каждое из них миссис Уайт отвечает возражением: «Да, но...» Хороший игрок может противостоять другим сколь угодно долго, пока они не сдадутся, и тогда миссис Уайт выигрывает. В некоторых случаях ей приходится разделаться с дюжиной или больше решений, чтобы подготовить унылую тишину, означающую ее победу.