12.12.2021, 14:51 | #61 |
Участник
|
Цитата:
т.е. вы предлагаете: = либо перекомпилировать работающие системы в Latest Target (ха-ха-ха, сразу отбросим этот вариант) = либо создать какую-то прокси-библиотеку, которая скомпилирована в Latest Target, а старые системы каким-то волшебным образом будут использовать эту прокси библиотеку. если так, как современный .NET разработчик, расскажите (лучше в отдельной ветке) как старые системы будут вызывать и принимать вызовы(!) Stream API, при условии что они ничего не знают о Stream API. Если не Stream API, то собственно вопрос "как правильно передать 100500 элементов коллекции"? и как предлагаемый вами способ в этом поможет Добавлено: и да, учтите, что gRPC основан на Stream API. Что почти все его хваленые преимущества - это преимущества Stream API. Последний раз редактировалось mazzy; 12.12.2021 в 15:09. |
|
12.12.2021, 20:34 | #62 |
Banned
|
Цитата:
Сообщение от mazzy
т.е. вы предлагаете: = либо перекомпилировать работающие системы в Latest Target (ха-ха-ха, сразу отбросим этот вариант) = либо создать какую-то прокси-библиотеку, которая скомпилирована в Latest Target, а старые системы каким-то волшебным образом будут использовать эту прокси библиотеку. Если не Stream API, то собственно вопрос "как правильно передать 100500 элементов коллекции"? С учетом реалий существования .NET и .Core так или иначе есть попытки писать такие прокси в .NET коммьюнити. Вот к примеру порт gRPC для Unity .Net 3.5 https://github.com/bwplotka/unity-grpc Я в свое время Java JSON поток в .NET сборку запихивал. Для AX кстати Уже даже не помню как. Так или иначе извратиться можно как угодно, было бы желание этим морковкам молиться. Ни в коем случае ничего не предлагаю эдакого. Но если в качестве варианта то .NET 3.5 .DLL сообщается с .NET Core DLL через COM interoperability .NET Framework and .NET Core COM interoperability https://docs.microsoft.com/en-us/sam...e-com-interop/ Но очевидно для меня что все это прекрасные глупости. Весь AX код он предназначен для того чтобы читать из базы данных и сохранять в базе данных. На мой взгляд, при возможности прямого доступа от базы к базе и таком размере передаваемых данных, тут и думать особо нечего. Правильно - дешево и надежно. Но если нужно использовать что-то модное и современное по разным причинам, то хоть Java хоть .NET любой как транспорт. Все модные слова в транспорте что берет из одной базы и кладет в другую. В свою очередь X++ работает с данными в этой базе. Цитата:
"как правильно передать 100500 элементов коллекции"
Конечно интересно обсудить чисто программистскую задачу из любви к исскуству. Но в нашем случае какое тут искусство? Размер окошка в камере для раздачи пищи и длина цепи - не предполагают такого понятия. Стул прибитый к полу - наше все. |
|
14.12.2021, 11:03 | #63 |
Модератор
|
|
|
|
За это сообщение автора поблагодарили: ax_mct (7). |
14.12.2021, 16:39 | #64 |
Banned
|
Готов забрать свои утверждения в пользу кролика.
Даже если где-то и можно сделать все через T-SQL, SSIS и прочее, при возможности пролоббировать и сделать проект на RabbitMQ, этим надо просто пользоваться как шансом изучить независимый, нужный и популярный продукт. В условиях кризиса наших скиллов это один из очень правильных путей. https://www.rabbitmq.com/tutorials/t...ne-dotnet.html |
|
|
|