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

[ax_mct]

Цитата:

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

я не знаю как разжевать еще, кроме как процитировать свое первое собщение.
в нем я постарался сформулировать задачу масимально кратко и четко.

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

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

Уверен, что недопонимание вызвано простейшей вещью. В силу особенности рыночной ниши, практически все здесь не кодеры, а скорее 3 в 1, программисты создающие решения для конечного пользователя.

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

В постановке вопроса просто никто не увидел задачи. А увидел некое решение. И как раз неправильно задачу подменять решением. В собственной голове неправильно.

Но если буквально то на вопрос ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?[/QUOTE]
то "правильно" на мой взгляд следуещее:

C точки зрения современного .NET разработчика. Если узко и без общей картины.

- использовать сборки (DLL) последних версий .NET на обеих серверах.
В X++ просто обращаться к этим DLL. Pagination, streaming, JSON - все опции.

Самое "правильное" c точки зрения .NET разработчика это использовать даже не WCF, а gRPC

https://docs.microsoft.com/en-us/asp...aspnetcore-6.0

https://grpc.io/docs/what-is-grpc/

Для опыта .NET это правильно. Ну там прокси понадобятся между .NET и .Core, но это остается все очень правильным для .NET разработчика.

С точки зрения же Microsoft, "правильно" это
SQL Data Sync for Azure
https://docs.microsoft.com/en-us/azu...r-sql-database
Все на крючок и это правильно.

С точки зрения клиента когда обе базы в одном домене, безусловно правильно
делать обмен данных на уровне баз данных. Как угодно хранимыми процедурами или из X++, не так важно.
WCF как веб-сервис дорога это компромисс когда порты закрыты, организации со своими полиси и пр.
Правильно потому что стоимость.

Кстати, обмениваться через SFTP можно и бинарными и зашифрованными файлами. Если единственный недостаток обмена файлами это открытость для редактирования то самое правильное это просто сделать так чтобы их нельзя было редактировать.
Это возможно правильно с точки зрения постановки цели.

[mazzy]

Цитата:

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

Цитата:

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

то "правильно" на мой взгляд следуещее:

C точки зрения современного .NET разработчика. Если узко и без общей картины.

- использовать сборки (DLL) последних версий .NET на обеих серверах.

ax2012 использует .net 4.0
ax2009 использует .net 3.5

мало того, что классические Аксапты используют старые .net, дык они используют разные версии .net. Собственно поэтому они в вопросе и упоминаются явно.

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

https://www.youtube.com/watch?v=G7wz4lZZo2s

[mazzy]

Цитата:

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

C точки зрения современного .NET разработчика.
...
- использовать сборки (DLL) последних версий .NET на обеих серверах.

Ладно, хер с ней, с Аксаптой.

т.е. вы предлагаете:
= либо перекомпилировать работающие системы в Latest Target (ха-ха-ха, сразу отбросим этот вариант)
= либо создать какую-то прокси-библиотеку, которая скомпилирована в Latest Target, а старые системы каким-то волшебным образом будут использовать эту прокси библиотеку.



если так, как современный .NET разработчик, расскажите (лучше в отдельной ветке) как старые системы будут вызывать и принимать вызовы(!) Stream API, при условии что они ничего не знают о Stream API.

Если не Stream API, то собственно вопрос "как правильно передать 100500 элементов коллекции"?
и как предлагаемый вами способ в этом поможет

Добавлено: и да, учтите, что gRPC основан на Stream API. Что почти все его хваленые преимущества - это преимущества Stream API.

[ax_mct]

Цитата:

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

т.е. вы предлагаете:
= либо перекомпилировать работающие системы в Latest Target (ха-ха-ха, сразу отбросим этот вариант)
= либо создать какую-то прокси-библиотеку, которая скомпилирована в Latest Target, а старые системы каким-то волшебным образом будут использовать эту прокси библиотеку.

Если не Stream API, то собственно вопрос "как правильно передать 100500 элементов коллекции"?

Да было бы желание у ударенного на голову .NET разработчика.
С учетом реалий существования .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 элементов коллекции"

То есть вариант ответа - через третью, возможно общую, базу данных.

Конечно интересно обсудить чисто программистскую задачу из любви к исскуству. Но в нашем случае какое тут искусство? Размер окошка в камере для раздачи пищи и длина цепи - не предполагают такого понятия. Стул прибитый к полу - наше все.