Я, как древний программист, больше люблю читаемость. А вы предлагаете заменить неплохо читаемый OR на селект с тремя подзапросами. Под предлогом того, что у вас это сработало. Так это может и сработало, только на ВАШЕЙ базе, с вашей версией БД и с вашим тюнингом. И с вашими сценариями. Может внезапно так оказаться, что это database-specific поведение и в качестве общего совета ваш совет - так себе. То, что совет так себе с точки зрения поддержки кода - я уже не сомневаюсь.
В конце 22го был уже .NET 6. Который LTS. И я на нём строил сервер для приложения на основе gRPC/protobuf. Под линуксом, да. И работал он прекрасно, полностью выжимая канал. Без перерасходов памяти, без сильной нагрузки на cpu. Без дедлоков. Хотя я не пробовал никогда лезть в задиспоженый стрим. Это как-то странно.
По мотивам той системы я уже писал статью на хабре.
Так что не знаю. Похоже, у нас разные дотнеты, разные линуксы и разные gRPC.
Я не знаю, почему у вас не едет дотнет под линукс. Я давно и плотно работаю с gRPC и у меня всё прекрасно едет. Что дотнет, что линукс, что gRPC - технологии, отлаженные годами. И это мейнстрим. И я сильно сомневаюсь, что в их связке есть какие-то проблемы. И я сильно сомневаюсь, что Го намного быстрее. Скорее всего вы умалчиваете какой-то интересный факт, а может и не заметили что-то.
Хотя именно в .Net такую критику - что "вы не умеете его готовить" - по данной проблеме, встречаю постоянно)
Я вам то же самое скажу. Вы не умеете его готовить. Прекрасно работает под большими нагрузками. В том числе и под линуксом.
Вам бы неплохо было бы определиться с требованиями к системе. gRPC работает через протобуф, протобуф - через https. Последний работает через TCP. Угадайте, включен ли у него алгоритм Нагла? Спойлер - он включен у всех по умолчанию. Соответственно, у вас будут задержки, лишние буфферы, лишний расход цпу. Если вас задержки не устраивают, то у вас путь один - к TCP. Это не значит, что нельзя "обогащать пакеты". Можно и ещё как. Простую информацию можно встраивать прямо в пакет (ну кто запретит пару байт с флагами вписать?), сложную и несинхронную оставить на gRPC.
То есть вы взяли gRPC/protobuf, только чтобы кидаться бинарными пакетами по 320 байт? Странное решение.
Тут бы подошёл обычный советский TCP. Отключаем Nagle (NoDelay = true) и вперёд кидаться друг друга пакетами практически безлимитно.
Протобуф - он какбы не для этого. Это суровый сериализатор сложных структур. И он отлично и быстро работает. Но вам он зачем? Если нет структуры - не нужен и сериализатор.
бизнес-логика - это то, чем люди будут заниматься даже при отсутствии какой-либо вычислительной техники вообще;
Без вычислительной техники - возможно. Без схемы данных - неа.
Бизнес-логика просто ничего не сможет сделать без модели. У всех звёзд одни и те же параметны, но разные. Процент пишется одними и теми же цифрами по одному и тому же правилу, от такой же цифры слева от процента. И получится абсолютно прямоугольная таблица, только нарисованная ручкой.
Спасибо. Я для написания прошлой статьи делал систему, где всё наоборот. Была модель, а из неё делались entity классы и proto-файлы. Вот репозиторий. Туда я тоже джойнов не завёз, хотя в оригинальной системе они были.
Ну как зачем? Модель создана для того, чтобы зеркалиться в базу. Это её назначение. Если мы этого не делаем, то у нас DB-first и модель нам не нужна.
Чистая архитектура рекомендует писать бизнес-логику так, как удобно для бизнес-домена, а база висит где-то там, за интерфейсом.
Так model-first и не вступает в противоречие с DDD. Они вообще на разных уровнях. Model-first решает проблему поддержки консистентности структуры базы и кода. В вашем случае можно было бы использовать, ну назовём это "3d model first". Когда предметная область задаёт структуру данных, то есть модель, а из модель подтягивает структуру БД до истинной и генерит код.
Но, на мой взгляд, это как-то очень скучно и сухо.
Я предпочёл бы скучно, сухо и предсказуемо незабываемому и захватывающему дух приключению по поискам непонятной ошибки. Может старый стал. Теперь люблю, когда скучно.
Конечно есть. Зачем вбухивать х10 денег на разработку своего, если уже есть то, что нужно и достаточно вбухать х1 денег на доработку под свои цели и поддержку?
<PublishAot>true</PublishAot> включает NativeAOT при публикации; <NativeLib>Shared</NativeLib> заставляет выпускать именно разделяемую библиотеку для C ABI; <SelfContained>true</SelfContained> собирает всё нужное внутрь, без внешнего .NET Runtime;
SelfContained не нужен в сборке Native AOT. Он просто ничего не делает там. При Native AOT всё и так собирается в один бинарь, никакого рантайма не требуется.
Я считаю, что не надо быть фаундером, чтобы разбираться в токсичности фаундеров. Хотя я тоже, в своём роде фаундер, аргументы в стиле "сперва добейся" вызывают некое отторжение.
Я, как древний программист, больше люблю читаемость. А вы предлагаете заменить неплохо читаемый OR на селект с тремя подзапросами. Под предлогом того, что у вас это сработало. Так это может и сработало, только на ВАШЕЙ базе, с вашей версией БД и с вашим тюнингом. И с вашими сценариями. Может внезапно так оказаться, что это database-specific поведение и в качестве общего совета ваш совет - так себе. То, что совет так себе с точки зрения поддержки кода - я уже не сомневаюсь.
Охлаждение экономики идёт с опережением графика (с)
В конце 22го был уже .NET 6. Который LTS. И я на нём строил сервер для приложения на основе gRPC/protobuf. Под линуксом, да. И работал он прекрасно, полностью выжимая канал. Без перерасходов памяти, без сильной нагрузки на cpu. Без дедлоков. Хотя я не пробовал никогда лезть в задиспоженый стрим. Это как-то странно.
По мотивам той системы я уже писал статью на хабре.
Так что не знаю. Похоже, у нас разные дотнеты, разные линуксы и разные gRPC.
Я не знаю, почему у вас не едет дотнет под линукс. Я давно и плотно работаю с gRPC и у меня всё прекрасно едет. Что дотнет, что линукс, что gRPC - технологии, отлаженные годами. И это мейнстрим. И я сильно сомневаюсь, что в их связке есть какие-то проблемы. И я сильно сомневаюсь, что Го намного быстрее. Скорее всего вы умалчиваете какой-то интересный факт, а может и не заметили что-то.
Я вам то же самое скажу. Вы не умеете его готовить. Прекрасно работает под большими нагрузками. В том числе и под линуксом.
Вам бы неплохо было бы определиться с требованиями к системе. gRPC работает через протобуф, протобуф - через https. Последний работает через TCP. Угадайте, включен ли у него алгоритм Нагла? Спойлер - он включен у всех по умолчанию. Соответственно, у вас будут задержки, лишние буфферы, лишний расход цпу. Если вас задержки не устраивают, то у вас путь один - к TCP. Это не значит, что нельзя "обогащать пакеты". Можно и ещё как. Простую информацию можно встраивать прямо в пакет (ну кто запретит пару байт с флагами вписать?), сложную и несинхронную оставить на gRPC.
То есть вы взяли gRPC/protobuf, только чтобы кидаться бинарными пакетами по 320 байт? Странное решение.
Тут бы подошёл обычный советский TCP. Отключаем Nagle (NoDelay = true) и вперёд кидаться друг друга пакетами практически безлимитно.
Протобуф - он какбы не для этого. Это суровый сериализатор сложных структур. И он отлично и быстро работает. Но вам он зачем? Если нет структуры - не нужен и сериализатор.
А нафенгхуа в GPU RISC-V? Там же совсем другая архитектура, которая SIMD с рождения.
С этим тоже не ясно. 24 бита на пиксель - этим кого-то можно удивить? Или тут про то, что видеовыход умеет выдавать такой формат сигнала?
Именно. В итоге тоже ничего не выделяется, только нет дополнительной когнитивной нагрузки.
Только нужен очень специфический программист, который умеет работать именно с вашим No-Code.
По этим соображениям я сделал абсолютно серый интерфейс. Цветом выделяются только немногие детали, вроде курсора, ok/cancel, да и то неброско.
Скрытый текст
Без вычислительной техники - возможно. Без схемы данных - неа.
Бизнес-логика просто ничего не сможет сделать без модели. У всех звёзд одни и те же параметны, но разные. Процент пишется одними и теми же цифрами по одному и тому же правилу, от такой же цифры слева от процента. И получится абсолютно прямоугольная таблица, только нарисованная ручкой.
Спасибо. Я для написания прошлой статьи делал систему, где всё наоборот. Была модель, а из неё делались entity классы и proto-файлы. Вот репозиторий. Туда я тоже джойнов не завёз, хотя в оригинальной системе они были.
Ну как зачем? Модель создана для того, чтобы зеркалиться в базу. Это её назначение. Если мы этого не делаем, то у нас DB-first и модель нам не нужна.
Так model-first и не вступает в противоречие с DDD. Они вообще на разных уровнях. Model-first решает проблему поддержки консистентности структуры базы и кода. В вашем случае можно было бы использовать, ну назовём это "3d model first". Когда предметная область задаёт структуру данных, то есть модель, а из модель подтягивает структуру БД до истинной и генерит код.
Я всё ждал, когда появится креационизм. Ну этот самый, где про Господа нашего Б-га.
Потому что такой отменный антинаучный бред обычно предваряет религиозные догматы.
Я предпочёл бы скучно, сухо и предсказуемо незабываемому и захватывающему дух приключению по поискам непонятной ошибки. Может старый стал. Теперь люблю, когда скучно.
Я помню этот опрос. Я хотел его честно пройти, но в первом вопросе не было пункта "у меня нет веб-камеры" и я закрыл его.
Конечно есть. Зачем вбухивать х10 денег на разработку своего, если уже есть то, что нужно и достаточно вбухать х1 денег на доработку под свои цели и поддержку?
Я стесняюсь спросить. Но спрошу. А как эти идиоты собираются окупать вложения в программу при одном пользователе (себе)?
SelfContained не нужен в сборке Native AOT. Он просто ничего не делает там. При Native AOT всё и так собирается в один бинарь, никакого рантайма не требуется.
Я считаю, что не надо быть фаундером, чтобы разбираться в токсичности фаундеров. Хотя я тоже, в своём роде фаундер, аргументы в стиле "сперва добейся" вызывают некое отторжение.