Здравствуйте, Serginio1, Вы писали:

V>>На один кадр могут быть миллионы вызовов, в нейтиве это быстро — на миллион вызовов будет что-то 350 микросекунд расходов, а в твойм случае 16 миллисекунд только стоимость самих вызовов, это 60 FPS ограничение сверху еще безо-всякой полезной работы, в нейтиве ограничение на той же сцене будет под 3 тыс FPS.
S> Нахрена тогда манагед код? Манагед как ты говоришь это скрипты, а тут он пополам с нативным кодом работает

Это в продолжении разговора, почему managed-код не используется для графических движков.
По моему ИМХО — из-за дорогого вызова нейтивных вещей.
Даже из обычного VB нейтивные ф-ии вызывались мгновенно.


V>>Открой Visual Studio Installer и установи тулчейн под Андроид.
V>>Вот какой пустой проект генерится:
S>И где там .NetStandard? там есть TargetFrameworkVersion>v11.0</TargetFrameworkVersion>
S>а он поддерживает .Net Standard 2.1

ОК, проверил — поддерживает.
Но продукт портировали на .Net Core пару лет назад.
Думается, ранее выхода очередной LTS-версии смысла дергаться нет.


V>>Почему я должен что-то признавать, если наш продукт, например, поставляемый в виде либы, на Андроиде заведомо не заведётся?
V>>Пока что только винды, линуха и макось.
V>>С Андроидом пока некоторая борьба.
S> Потому что платформозависимый? Или все таки сделанный под .NetStandard 2.1?

Конечно, платфрменнозависимый.
С другой стороны, там под капотом обычные линуха, поэтому, вполне возможно, что Андроид будет окучен.
Тем более, что рядом подсказали, что .Net 6.0 должен заменить собой моно-рантайм Хamarin-а.
(надо будет проверить при выходе)


V>>Зачем же тогда нужен Xamarin, если тогда можно было бы пользовать WPF? ))
S>Нет поэтому и помечаются как платформозависимые. Часть можно сделать через условную компиляцию.

ЧТД.
Через условную компиляцию ты будешь транзитивно порождать платформенно-зависимые бинари, прощай обещанная "чистая кроссплатформенность". ))

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


S>Поэтому и развивают Xamarin.Forms где тот же гуй один для всех, а реализация для каждой платформы своя.

Тебя самого не смущает, что ровно с этой же целью был разработан Silverlight, WPF и прочие?
Или вот MAUI вышел.
Глаза не разбегаются от родственных технологий? ))


V>>Из них чуть ли не половина — вспомогательных для этих сред, в основном для целей разработки.
V>>А целевых прикладных — тут до нейтива как до Европы раком еще.
S> Да любые библиотеки начиная от xml,json заканчивая EntityFramework и прочими тяжеловесными продуктами.

))


V>>Т.е., завернуть, приготовить, упаковать и отправить в некую "черную дыру" (по вашим представлениям), где всё полезное и происходит, собсно.
S>Там есть апи, и довольно жидкое. А вот EntityFramework там и генерация кода в рантайме и тот же любимый сишниками Sourcecode Generator.

Ну, в C++ изначально маппинг прост, поэтому, выделенные ORM непопулярны.
Да и банальный шаблон Фасад ничего не стоит в рантайме, т.е. штрафа за абстракцию нет.

Что касается общения с БД — в плюсах принято вручную контроллировать ресурсы, например, самим управлять пулом соединений, самим решать, как именно посылать запросы к базе (синхронно, безблокировочно или асинхронно), как ожидать ответ и т.д. В дотнете же это всё "даётся сверху" без малейшей возможности настроить под себя. Просто тебе дан некий "наиболее общий сценарий", скажи спасибо и за это.

Ну и, низлежащие драйвера связи с БД дают доступ к памяти прочитанной строки БД, т.е., в отличие от дотнетных дров, нет надобности копировать эти данные, да еще в "вертикальное" представление в памяти, когда каждый столбец рекордсета представлен массивом. Прямо из поданной драйвером памяти данные непосредственно используются по чтению.

В общем, практики резко другие.
Тиков проца потребляется в разы меньше.
Особенно когда речь идёт о локальных in-proc базах-хранилищах и непосредственного использования их низкоуровневого АПИ, там и вовсе эффективность на порядки выше.

В последних дотнетах тоже есть возможность переписать драйверы общения с БД на похожий манер (через упомянутую сборку Unsafe), но вряд ли это сделают, бо легаси такое легаси...

И да, в плюсах полно реализаций "самого общего сценария"
https://oatpp.io/docs/components/orm/
(с полутыка найдёшь еще несколько)
Но как-то явного лидера не выявилось, по всем перечисленным причинам.

В общем, не та область, которая требует тщательного предварительного окучивания.
В нейтиве выгодней делать DAL прямо на уровне DB-провайдера, а не абстрагировать ORM от DB-провайдера, как это сделано в дотнете и ссылке выше на плюсовый проект.
Это тоже важная причина, ИМХО, потому что позволяет написать наиболее эффективный код под каждого провайдера.

Абстрагировать выгодней россыпь хелперов в DDD-стиле, причём, через compile-time абстракции, т.е. через шаблонный код, где хелперы переиспользуются в конкретных реализациях DAL.