В принципе и ОРМ умеет эффективно работать только на таблицах (это когда вы еще можете поменять одну БД на другую), далее идет точка невозврата (в том же EF не для всех провайдеров есть поддержка вызова хранимок, вьюх и тд.)
Если работа с базой выходит за рамки таблиц, и БД начинает обрастать логикой, то от ОРМ надо отказываться (тк гибрид с рукопашными запросами это уже зло…), используя ОРМ только для транспорта.
Некоторые дополнения с тз архитектурного (не ресурсного) выбора.
-ORM это классная штука чтобы накидать с нуля demo с подходом code-first;
-ORM неплох и справляется со своими задачами, если БД используется в проекте топорно-типовым образом (ограничивается чтением и записью на таблицах);
-ORM нам не подойдет, если наша БД с приложением используется для составления сложных аналитических или иных отчетов, например (не хватит гибкости на написание запросов, будет преобладать Raw Sql). Равно как и для приложений с толстым слоем логики в базе.
-ORM нежелателен в сложных корпоративных проектах, рассчитанных на высокую нагрузку и нулевую толерантность у потере данных (нужен полный контроль над процесссом, отсутствие рисков и более высокая производительность)
PS по опыту (.Net a), если резюмировать. До массового внедрения .net core (годы 2018-19) большинство корпоративных приложений были «базоцентричными», и несмотря на наличие EF работа с сырым SQL часто требовалась, для составления сложных запросов и оптимизации, поэтому зачастую ORM либо не использовался, либо существовал в виде гибрида.
С переходом на микро-сервисную архитектуру, «базоцентричность» стала сходить на нет, проще сделать 10 адаптированных баз и перекачивать данные чем возиться с одной большой. Посему, да, скорость разработки (ОРМ в помощь) становится важнее навыка писать производительные запросы руками. Однако, отдельный плат технологически сложных проектов (не легаси), где критичен перформанс и полный контроль над процессом, все равно имеет место быть, и в этих случаях от ОРМ приходится отказываться.
Что касается качества рукописных запросов, такие слои покрываются интеграционными тестами (равно как и с ОРМ это надо делать, несмотря на контроль типов масса возможностей выстрелить в ногу остаются). Просто вместо человеческих ошибок у вас риск «чуда из коробки», чье влияние и поведение может быть неочевидным и давать нежелательные эффекты.
Если кратко, то инструментальные измерения деградации показывали длительное время на операциях чтения/записи при получении/отправке пакетов из/в сеть на больших RPS (расчеты приводил выше).
Обязанности аналитика могут различаться в разных компаниях, мне более близок подход в текущей финансовой организации: Бизнес-аналитик и Системный аналитик.
Первая категория хорошо разбирается в предметной области, бизнес-потребностях и т.д. Вторая является "связующим звеном" между бизнесом и разработкой, те что то между техническим писателем и архитектором (кому насколько хватает компетенций).
По своему мнению (разработчика), люди без технического опыта могут, конечно, описать, как должна работать система (технически), протоколы взаимодействия, структуру БД, интеграции, и т.д. (как это описывают грамотные архитекторы), но они не знают/не видят рисков и возможных сложных ошибок в решениях (те их знания - скорее теоретические, не подкрепленные практическим опытом). Хорошие архитектурные решения с их стороны требуют, как минимум, плотных консультаций с разработкой.
Нужна экспертиза по Си и грамотный разработчик в команде, не всегда (редко когда) есть желание нанимать новых людей и плодить зоопарк. К тому же на GO побольше кадровый выбор.
Могу добавить что информация актуальна на конец 2022, может быть в .Net 8 - более стабильной мажорной версии - это поведение поменялось в лучшую сторону.
PS помню еще .net 5, где попытки обратиться к GRPC-стриму, который был переведен в Dispose состояние (программистские ошибки, да), но все же такой баг в коде приводил к дедлокам на уровне платформы и stopper-у всего приложения.
Так что в те времена складывалось впечатление о "сырости" .net-ного GRPC.
Все же хочется снизить риск человеческих ошибок при разборе голых байт, и в принципе использовать более удобные инструменты если нет противопоказаний к обратному.
Тут скорее вопрос к реализации сетевого стека в части GRPC на .net под Linux, если при прочих равных такое же решение на GO прекрасно едет.
Так как в реальном проекте главное - это именно решить проблему, с гарантией, что лучше чем пытаться тюнить текущий стек «на костылях». Хотя именно в .Net такую критику - что "вы не умеете его готовить" - по данной проблеме, встречаю постоянно)
Не совсем так. Голый TCP - это стандарт Asterisk а, и мы должны были его придерживаться только в первой точке в цепочке по работе с голосом, которая взаимодействует именно с Астером. Далее - по GRPC цепочке - пакеты можно было укрупнять и обогащать, увеличивая задержки + появляются сквозные идентификаторы, признаки попутного анализа пакетов голоса (например, есть ли в них речь или пакет пустой), те в структуре GRPC пакетов уже не только голые аудио-байты. К тому же же yandex-speech-recognition или text-to-speech работают по протоколу GRPC.
Понятно зачем это делается. Учитывая что проблема с военным столом за последний год работы в компании не была решена никак. А тут еще и закон об электронных повестках вышел.
Менеджер, который только тупо тыкает всех палкой, мало разбираясь в происходящем, либо выгорел либо профнепригоден.
Основа одинаковая если у вас «все на таблицах».
В принципе и ОРМ умеет эффективно работать только на таблицах (это когда вы еще можете поменять одну БД на другую), далее идет точка невозврата (в том же EF не для всех провайдеров есть поддержка вызова хранимок, вьюх и тд.)
Если работа с базой выходит за рамки таблиц, и БД начинает обрастать логикой, то от ОРМ надо отказываться (тк гибрид с рукопашными запросами это уже зло…), используя ОРМ только для транспорта.
Некоторые дополнения с тз архитектурного (не ресурсного) выбора.
-ORM это классная штука чтобы накидать с нуля demo с подходом code-first;
-ORM неплох и справляется со своими задачами, если БД используется в проекте топорно-типовым образом (ограничивается чтением и записью на таблицах);
-ORM нам не подойдет, если наша БД с приложением используется для составления сложных аналитических или иных отчетов, например (не хватит гибкости на написание запросов, будет преобладать Raw Sql). Равно как и для приложений с толстым слоем логики в базе.
-ORM нежелателен в сложных корпоративных проектах, рассчитанных на высокую нагрузку и нулевую толерантность у потере данных (нужен полный контроль над процесссом, отсутствие рисков и более высокая производительность)
PS по опыту (.Net a), если резюмировать. До массового внедрения .net core (годы 2018-19) большинство корпоративных приложений были «базоцентричными», и несмотря на наличие EF работа с сырым SQL часто требовалась, для составления сложных запросов и оптимизации, поэтому зачастую ORM либо не использовался, либо существовал в виде гибрида.
С переходом на микро-сервисную архитектуру, «базоцентричность» стала сходить на нет, проще сделать 10 адаптированных баз и перекачивать данные чем возиться с одной большой. Посему, да, скорость разработки (ОРМ в помощь) становится важнее навыка писать производительные запросы руками. Однако, отдельный плат технологически сложных проектов (не легаси), где критичен перформанс и полный контроль над процессом, все равно имеет место быть, и в этих случаях от ОРМ приходится отказываться.
Что касается качества рукописных запросов, такие слои покрываются интеграционными тестами (равно как и с ОРМ это надо делать, несмотря на контроль типов масса возможностей выстрелить в ногу остаются). Просто вместо человеческих ошибок у вас риск «чуда из коробки», чье влияние и поведение может быть неочевидным и давать нежелательные эффекты.
Увы, легаси, этот проекта на 6.0 живет (вместе со всей конторой).
Если кратко, то инструментальные измерения деградации показывали длительное время на операциях чтения/записи при получении/отправке пакетов из/в сеть на больших RPS (расчеты приводил выше).
Обязанности аналитика могут различаться в разных компаниях, мне более близок подход в текущей финансовой организации: Бизнес-аналитик и Системный аналитик.
Первая категория хорошо разбирается в предметной области, бизнес-потребностях и т.д. Вторая является "связующим звеном" между бизнесом и разработкой, те что то между техническим писателем и архитектором (кому насколько хватает компетенций).
По своему мнению (разработчика), люди без технического опыта могут, конечно, описать, как должна работать система (технически), протоколы взаимодействия, структуру БД, интеграции, и т.д. (как это описывают грамотные архитекторы), но они не знают/не видят рисков и возможных сложных ошибок в решениях (те их знания - скорее теоретические, не подкрепленные практическим опытом). Хорошие архитектурные решения с их стороны требуют, как минимум, плотных консультаций с разработкой.
Нужна экспертиза по Си и грамотный разработчик в команде, не всегда (редко когда) есть желание нанимать новых людей и плодить зоопарк. К тому же на GO побольше кадровый выбор.
Могу добавить что информация актуальна на конец 2022, может быть в .Net 8 - более стабильной мажорной версии - это поведение поменялось в лучшую сторону.
PS помню еще .net 5, где попытки обратиться к GRPC-стриму, который был переведен в Dispose состояние (программистские ошибки, да), но все же такой баг в коде приводил к дедлокам на уровне платформы и stopper-у всего приложения.
Так что в те времена складывалось впечатление о "сырости" .net-ного GRPC.
Все же хочется снизить риск человеческих ошибок при разборе голых байт, и в принципе использовать более удобные инструменты если нет противопоказаний к обратному.
Тут скорее вопрос к реализации сетевого стека в части GRPC на .net под Linux, если при прочих равных такое же решение на GO прекрасно едет.
Так как в реальном проекте главное - это именно решить проблему, с гарантией, что лучше чем пытаться тюнить текущий стек «на костылях». Хотя именно в .Net такую критику - что "вы не умеете его готовить" - по данной проблеме, встречаю постоянно)
Не совсем так. Голый TCP - это стандарт Asterisk а, и мы должны были его придерживаться только в первой точке в цепочке по работе с голосом, которая взаимодействует именно с Астером. Далее - по GRPC цепочке - пакеты можно было укрупнять и обогащать, увеличивая задержки + появляются сквозные идентификаторы, признаки попутного анализа пакетов голоса (например, есть ли в них речь или пакет пустой), те в структуре GRPC пакетов уже не только голые аудио-байты. К тому же же yandex-speech-recognition или text-to-speech работают по протоколу GRPC.
Понятно зачем это делается. Учитывая что проблема с военным столом за последний год работы в компании не была решена никак. А тут еще и закон об электронных повестках вышел.