Разве что LINQ принимается :)
Да и-то в качестве «запросов к БД» или куда-либо ещё.
Что автомаппер что FluentAssertions, что Linq2Objects на простых лямдах достаточно нормально отжимаются.
Ну не черт сколько, возможность на авто-пропертях делать readonly setter появилась достаточно недавненько.
Плюс если вспомнить любимого Рихтера, то он ненавидит проперти со времен первого издания своей книги про CLR и говорит что стоит явно писать методы, которые не несут «многозначности то-ли переменная то ли метод» :D
Но это я уже подтроливаю немножко, да. Еще Рихтер везде sealed рекомендовал, помнится.
Можете мне привести пример частого использования expression trees в кровавом энтерпрайзе? Мне действительно интересно.
Последний раз я их ковырял когда правил форк от ORM и больше «с ходу» не припомню необходимости.
Про дженерики тоже холиварный вопрос, в джаве они есть, причем с неплохой ковариантностью-контрвариантностью из коробки, ala
List<? extends A> myList1
List<? super B> myList2
Ну да, type erasure. Сейчас минусаторы набегут, но в большинстве повседневных задачах он не мешает.
Мы же про продуктивность? Почему не вспоминаем про тот же Lombok
@NonNull
@AllArgsConstructor
@ToString
@EqualsAndHashCode Getter/@Setter
Вот это про продуктивность. И никакого бойлерплейта.
В дотнете такое возможно огромными костылями ala Postsharp (который почти загнулся из-за платности / заметно возрастающего времени компиляции), ну или Fody (который тоже не оч.популярен). Появилось ли что-то похожее в .Core?
Composition Root оно называется и подобным образом на русский язык не переводится.
Точка сборки — это к Кастанеде Карлосу ;)
Явовские контейнеры можно конфигурировать кучей способов (сходу назову штук 5), при этом бут добавляет удобную авто-конфигурацию «из коробки». Не будьте столь категоричны, это неконструктивно и неприятно читать.
Не нарушал я ничего, речь идет о домашнем компьютере и pet-проектах. Visual Studio Community хватает «на всё что угодно» (в отличие от ужасающей Express которая была ранее давно). А вот в IDEA Community жадинки отрезали использование спринга с бутом, что отвратительно и неприятно.
Причем здесь каменный век, в Java тоже есть пакетные менеджеры и появились они гораздо раньше чем возник тот же nuget. Но вот принято референсы прям в pom.xml руками прописывать. Вопрос привычки и удобства. Поначалу выглядит странновато, но по факту на самом деле оказывается удобней чем отдельный CLI.
Наконец-то принес, спустя 15 лет. Минусов «выбора» масса — в одном проекте Unity, в другом — Autofac, в третьем StructureMap, а в четвертом NInject — и все они различаются в API и при этом одинаковые на 95%. Здесь огромный плюс джавовских JSR виден, надеюсь, всем.
Транзакции — скорее про аннотацию @Transactional.
OWIN еще и Embended Server дает. Еще немного, и Микрософт придумают свой H2 (или уже придумали?).
.Net Core это попытка выкинуть платформу, разрабатываемую 15 последних лет и переписать/переосмыслить всё заново. Насколько эта идея может быть успешна в нынешних реалиях, покажет только время.
Но то что большинство текущих проектов на .NET (не Core) внезапно стало Legacy — это факт.
Скорее всего схвачу минусов (на хабре культ Jetbrains), но это хайп. Да еще и платный.
Я года 3-4 работал с VS Community и ни одной мысли о Pro не возникало — хватало всего что есть. А в Idea Community со спрингом нормально работать невозможно — сделано всё чтобы люди платили деньги.
Вся ирония в том, что некоторое время назад все.нетчики подкалывали джавистов про «программирование на xml». А сейчас этот самый xml остался, как необходимость, как раз в .Net.
JEE мне кажется некорректно использовать в данном контексте, т.к. это набор спек, половину из которых входят тот же спринг.
EJB это грубо говоря контейнер (я верю что вы это знаете, просто пишу для синхронизации терминологического контекста) и именно альтернативой ему стал в свое время спринг. Это собирательное название для «того что не спринг» и именно эту аббревиатуру обычно не пишут в спринговых вакансиях.
Но концептуально вы правы, наиболее корректно использовать JEE Server (именно эту бирку «лепят» (или лепили?) себе всякие jboss-ы). Или уже правильно Jakarta Server? :)
Спасибо за комментарий. Сфокусированность микрософта на своем личном облаке это одна из вещей, которая меня очень настораживает в. net core и почему я не очень верю в его будущее (по крайней мере в российских реалиях). Весь кровавый интерпрайз попытались оставить в старом заброшенном .net 4.6+ и всё переписать заново в core где сегодня csproj (xml), завтра json (который project) а потом опять xml (решили все-таки не выкидывать msbuild), зато в entity framework core банально уже n лет нет lazy loading (т. е. оно не Enterprise ready). Для облаков и микросервисов в них .net core возможно действительно вполне себе ок.
Фаулер придумал DI(njection), Мартин придумал DI(nversion).
И где-то рядом «сверху» всегда был IoC. И все они где-то пересекаются, действительно четких границ нет, как бы нам этого не хотелось.
Да и-то в качестве «запросов к БД» или куда-либо ещё.
Что автомаппер что FluentAssertions, что Linq2Objects на простых лямдах достаточно нормально отжимаются.
Плюс если вспомнить любимого Рихтера, то он ненавидит проперти со времен первого издания своей книги про CLR и говорит что стоит явно писать методы, которые не несут «многозначности то-ли переменная то ли метод» :D
Но это я уже подтроливаю немножко, да. Еще Рихтер везде sealed рекомендовал, помнится.
Последний раз я их ковырял когда правил форк от ORM и больше «с ходу» не припомню необходимости.
Про дженерики тоже холиварный вопрос, в джаве они есть, причем с неплохой ковариантностью-контрвариантностью из коробки, ala
List<? extends A> myList1
List<? super B> myList2
Ну да, type erasure. Сейчас минусаторы набегут, но в большинстве повседневных задачах он не мешает.
Мы же про продуктивность? Почему не вспоминаем про тот же Lombok
@NonNull
@AllArgsConstructor
@ToString
@EqualsAndHashCode
Getter/@Setter
Вот это про продуктивность. И никакого бойлерплейта.
В дотнете такое возможно огромными костылями ala Postsharp (который почти загнулся из-за платности / заметно возрастающего времени компиляции), ну или Fody (который тоже не оч.популярен). Появилось ли что-то похожее в .Core?
Точка сборки — это к Кастанеде Карлосу ;)
Явовские контейнеры можно конфигурировать кучей способов (сходу назову штук 5), при этом бут добавляет удобную авто-конфигурацию «из коробки». Не будьте столь категоричны, это неконструктивно и неприятно читать.
Транзакции — скорее про аннотацию @Transactional.
OWIN еще и Embended Server дает. Еще немного, и Микрософт придумают свой H2 (или уже придумали?).
Но то что большинство текущих проектов на .NET (не Core) внезапно стало Legacy — это факт.
Я года 3-4 работал с VS Community и ни одной мысли о Pro не возникало — хватало всего что есть. А в Idea Community со спрингом нормально работать невозможно — сделано всё чтобы люди платили деньги.
А как насчет many-to-many отношений?
EJB это грубо говоря контейнер (я верю что вы это знаете, просто пишу для синхронизации терминологического контекста) и именно альтернативой ему стал в свое время спринг. Это собирательное название для «того что не спринг» и именно эту аббревиатуру обычно не пишут в спринговых вакансиях.
Но концептуально вы правы, наиболее корректно использовать JEE Server (именно эту бирку «лепят» (или лепили?) себе всякие jboss-ы). Или уже правильно Jakarta Server? :)
Спасибо за комментарий. Сфокусированность микрософта на своем личном облаке это одна из вещей, которая меня очень настораживает в. net core и почему я не очень верю в его будущее (по крайней мере в российских реалиях). Весь кровавый интерпрайз попытались оставить в старом заброшенном .net 4.6+ и всё переписать заново в core где сегодня csproj (xml), завтра json (который project) а потом опять xml (решили все-таки не выкидывать msbuild), зато в entity framework core банально уже n лет нет lazy loading (т. е. оно не Enterprise ready). Для облаков и микросервисов в них .net core возможно действительно вполне себе ок.
www.theserverside.com/discussions/thread/23358.html
Фаулер придумал DI(njection), Мартин придумал DI(nversion).
И где-то рядом «сверху» всегда был IoC. И все они где-то пересекаются, действительно четких границ нет, как бы нам этого не хотелось.