Микросервис per entity — как и практически любое архитектурное разделение per entity — плохая идея за редкими исключениями. Делите по бизнесу, по его процессам.
Часто встречаю такую тему, кстати, "у нас Х таблиц в базе, куда нам столько микросервисов", есть ощущение что это каргокульт: если у меня есть микросервис, скажем, форумного движка, то в нем очевидно окажется сущность Forum и называться он скорее всего будет ForumService. Но при этом в нем будут содержаться и темы, и модераторы, и комментарии, и спасибы, и прочие. Но со стороны все равно появится ощущение, что это сервис только форумов.
Можете поподробнее про первую ложь, пожалуйста?
Сейчас посчитал — реально пять лет писал на MSSQL со старым EF, переехал на постгрес за выходные. Потом была схожая история с переездом с MSSQL на MySQL и на AuroraDb (последнее не особо валидно, поскольку аврора это форк innodb). Возможно, дело в каких-то фундаментальных различиях оракла с постгресом?
Не, ну мне в университете хватило не то что срачей «МГУ против Бауманки», но даже «мехмат против ВМК» и даже «механики против математиков».
Но вообще, если по теме, я никакой особой корреляции между уровнем программиста и высшим образованием не нашел за годы своего опыта, а анекдотических контрпримеров хватает и в одну, и в другую стороны.
Сам из-за своей этой деформации (я мехмат бросил на середине) я никогда в графу образования на собесах не смотрю, ко мне вроде тоже уже не смотрят, благо в резюме есть чего еще почитать, но главный принцип обиженного отечественным высшим — если меня не берут, потому что не подхожу образованием, то и мне вряд ли понравится на таких ребят работать.
На одной из работ мне сказали что так здорово что у меня есть гитхаб и статья на хабре, а потом оказалось что ни гитхаб ни статью никто не читал :)
Впрочем, оно же сработало!
Скорее всего (я надеюсь), они гонятся в первую очередь за повторением функционала EF 6.x, а уже потом за наполнением свежим функционалом. Пока у нас все еще нет аггрегационных функций в группированных запросах, наличие прямого доступа к m2m-сущностям как-то мало погоды сделает.
Слабость в том, что нельзя определить, какие аргументы принимает функция и хотя бы их имена, раз уж тип нельзя по понятным причинам. Ещё слабость в том, что надо хардкодить названия в отсутствие nameof.
Неудобство в том что нельзя отличить методы от свойств без лишних телодвижений с typeof, hasOwnProperty и прочим там. Я никогда не видел, чтобы метод переопределяли в свойство, хотя это технически возможно. Да, я понимаю про функции высшего порядка, но на js в основном пишут не в фп, а в ооп стиле, где методы имеют особое значение.
Я уточню, на всякий пожарный, что это конечно не финальная версия рефлексия в жиеси, но пока что она выглядит примерно как промисы без async/await синтаксиса.
Окей, я, очевидно, ушел в другую степь. Я никоим разом не имел в виду, что в языках со слабой динамической типизацией есть какие-то проблемы с рефлексией. Я говорил, что данные проблемы есть в JS, и что хотя код вида
var x = new X()
x['myMethod'] = () => console.log('hi')
можно считать рефлексией, но вообще это крайне слабый и неудобный механизм. В то же время, во многих языках с сильной статической типизацией механизм рефлексии гораздо более функционален, пусть и не настолько прост в использовании. Например, в шарпах.
Пхп, конечно, тоже любопытный язык, но тут шла речь о другом все-таки.
Согласен. Это отличный способ отстрелить себе ногу и должен применяться с осторожностью даже в строго типизированных языках. А в JS за такое надо как-то наказывать и желательно жестоко.
Я, конечно, напрямую не упомянул SetValue, но он там тоже есть. Если бы вы внимательно прочитали мой ответ, то увидели бы, что я привел примерами Mocks, IoC, AOP — далеко не readonly примеры. Все это в шарпе существует.
Если на то пошло, то рефлексия в статически типизированных языках в разы сильнее этой идеи «обратись к методу по строке его имени» — поэтому там и существуют пресловутые IoC-контейнеры и Mock-библиотеки. А в JS приходится довольствоваться spy(«myMethod») и иже с ним.
Не знаю, какие вы примеры смотрели, на MSDN, например, все совершенно прозрачно — GetProperty(«DontDoIt»).GetValue(myObject);
Считается, что использование рефлексии должно быть явно оправдано, какой-то конкретной необходимостью. Процесс обнаружения типов, процесс их создания на лету, изменения и прочего всего такого несколько расходится с основными принципами статической типизации.
Как сказал товарищ Free_ze если вы пользуетесь таким функционалом, вы либо совершенно точно понимаете, что вы делаете, и иначе это не сделать (Mocks-библиотеки, IoC-контейнеры, AOP-фреймворки), либо вы претендуете на свой зал славы на говнокод.ру.
Ну я бы сказал, что это уже не фуллстек-девелопер, а скорее фуллстек-вообще. Здорово, когда человек никому ничего не доказывает, а просто делает работу и понимает, для кого он ее делает. Респект вам.
В среднем по больнице, к сожалению, как и любые титулы, этот скорее связан с фаллометрией и используется далеко не во благо.
А есть ли возможность гонять эти тесты без непосредственно базы данных? Потому что для бэкенда как бы это практически всегда запросто. Более того, в моем родном дотнете скоро обещают возможность запуска owin-based-приложух прямо в памяти. Типа можно писать интеграционные тесты на ваш API вообще не запуская сервер.
Я сам вообще стараюсь хранимки использовать по минимуму. Понятное дело, что иногда они дают важный буст производительности, особенно учитывая, что ORM не серебрянная пуля и часто генерят диковатые запросы. Спросил не с целью «о, если мне еще юнит-тестов там подвезут, все буду на скулях писать», а с вопросом в духе «а чо, в мире есть проекты, где хорошо уживаются CI/CD, TDD и хранимки?» Потому что у меня на проекте они уживаются, но с очевидностью первое берет верх.
В своем петпроекте в разделе форума "ошибки" я ввёл и описал подобные правила заведения багрепортов. Обычные юзеры, многие далёкие от разработки или тестирования стали ВСЕГДА писать нормальные описания ошибок. Я не представляю как люди за зарплату могут этого не делать. Похоже на саботаж, мне кажется.
Вот уроды, написали нечто интересное и не дают порушить систему!
Микросервис per entity — как и практически любое архитектурное разделение per entity — плохая идея за редкими исключениями. Делите по бизнесу, по его процессам.
Часто встречаю такую тему, кстати, "у нас Х таблиц в базе, куда нам столько микросервисов", есть ощущение что это каргокульт: если у меня есть микросервис, скажем, форумного движка, то в нем очевидно окажется сущность Forum и называться он скорее всего будет ForumService. Но при этом в нем будут содержаться и темы, и модераторы, и комментарии, и спасибы, и прочие. Но со стороны все равно появится ощущение, что это сервис только форумов.
Сейчас посчитал — реально пять лет писал на MSSQL со старым EF, переехал на постгрес за выходные. Потом была схожая история с переездом с MSSQL на MySQL и на AuroraDb (последнее не особо валидно, поскольку аврора это форк innodb). Возможно, дело в каких-то фундаментальных различиях оракла с постгресом?
Но вообще, если по теме, я никакой особой корреляции между уровнем программиста и высшим образованием не нашел за годы своего опыта, а анекдотических контрпримеров хватает и в одну, и в другую стороны.
Сам из-за своей этой деформации (я мехмат бросил на середине) я никогда в графу образования на собесах не смотрю, ко мне вроде тоже уже не смотрят, благо в резюме есть чего еще почитать, но главный принцип обиженного отечественным высшим — если меня не берут, потому что не подхожу образованием, то и мне вряд ли понравится на таких ребят работать.
На одной из работ мне сказали что так здорово что у меня есть гитхаб и статья на хабре, а потом оказалось что ни гитхаб ни статью никто не читал :)
Впрочем, оно же сработало!
Слабость в том, что нельзя определить, какие аргументы принимает функция и хотя бы их имена, раз уж тип нельзя по понятным причинам. Ещё слабость в том, что надо хардкодить названия в отсутствие nameof.
Неудобство в том что нельзя отличить методы от свойств без лишних телодвижений с typeof, hasOwnProperty и прочим там. Я никогда не видел, чтобы метод переопределяли в свойство, хотя это технически возможно. Да, я понимаю про функции высшего порядка, но на js в основном пишут не в фп, а в ооп стиле, где методы имеют особое значение.
Я уточню, на всякий пожарный, что это конечно не финальная версия рефлексия в жиеси, но пока что она выглядит примерно как промисы без async/await синтаксиса.
можно считать рефлексией, но вообще это крайне слабый и неудобный механизм. В то же время, во многих языках с сильной статической типизацией механизм рефлексии гораздо более функционален, пусть и не настолько прост в использовании. Например, в шарпах.
Пхп, конечно, тоже любопытный язык, но тут шла речь о другом все-таки.
Если на то пошло, то рефлексия в статически типизированных языках в разы сильнее этой идеи «обратись к методу по строке его имени» — поэтому там и существуют пресловутые IoC-контейнеры и Mock-библиотеки. А в JS приходится довольствоваться spy(«myMethod») и иже с ним.
Считается, что использование рефлексии должно быть явно оправдано, какой-то конкретной необходимостью. Процесс обнаружения типов, процесс их создания на лету, изменения и прочего всего такого несколько расходится с основными принципами статической типизации.
Как сказал товарищ Free_ze если вы пользуетесь таким функционалом, вы либо совершенно точно понимаете, что вы делаете, и иначе это не сделать (Mocks-библиотеки, IoC-контейнеры, AOP-фреймворки), либо вы претендуете на свой зал славы на говнокод.ру.
В среднем по больнице, к сожалению, как и любые титулы, этот скорее связан с фаллометрией и используется далеко не во благо.
Я сам вообще стараюсь хранимки использовать по минимуму. Понятное дело, что иногда они дают важный буст производительности, особенно учитывая, что ORM не серебрянная пуля и часто генерят диковатые запросы. Спросил не с целью «о, если мне еще юнит-тестов там подвезут, все буду на скулях писать», а с вопросом в духе «а чо, в мире есть проекты, где хорошо уживаются CI/CD, TDD и хранимки?» Потому что у меня на проекте они уживаются, но с очевидностью первое берет верх.
В своем петпроекте в разделе форума "ошибки" я ввёл и описал подобные правила заведения багрепортов. Обычные юзеры, многие далёкие от разработки или тестирования стали ВСЕГДА писать нормальные описания ошибок. Я не представляю как люди за зарплату могут этого не делать. Похоже на саботаж, мне кажется.