Я прям представляю, как приходит к нам сеньор, который последние 5 лет пилил документооборот, а у нас шоп платформа с 150+ интеграциями. И мы ему такие, к примеру, а нам надо прикрутить серверный фейсбук пиксель с LDU CCPA и всеми нужными событиями и данными, ну и морду в админку к этому всему. И он такой, "ок, ща почитаю википедию, завтра можно будет что-то посмотреть". Он только в том, как проект устроен, будет разбираться недели полторы. И окружение для разработки настраивать полдня минимум. А в стартапах порой так чудно все устроено, agile завязанный узлом порой творит чудеса, которые выливаются в "офигительные технические решения", "исторически так сложилось" или "зачем здесь это? и зачем это? а это?! ... ах, вот зачем..". Друго дело, конечно, если ему дали простую отдельностоящую задачку в духе сделай crud для вот этой фигни и он делал её две недели.
там David Woodhouse все же написал ответочку. интересующимся советую ознакомиться со всей веткой. retpoline на skylake не панацея, как оказалось. Негодование Линуса понятно, но тут либо ждать, либо латать, используя лучшие доступные варианты. И еще, видимо, нужно писать развернутые комменты к патчам;)
Можно просто посчитать на сколько денег продали астралинукса и других отечественных линуксов за последний год для гос и около контор. И их реально сейчас пытаются активно внедрять. Возникла потребность в ПО для линуксов. У многих уже были свои работающие решения на dotnet на винде, кто-то решил заказать замену своим еще dos программам. Выход dotnet core 2 сильно помог компаниям, не меняя программистов и не переписывая весь код, постараться вписаться в этот праздник импортозамещения.
По базам: postgresql там из коробки даже в special edition (хотя не самый новый), кому не нравится, есть postgrespro с плюшками и сертификатом. Работает с EntityFramework.
Требования на разработку включают исходники на все ПО с совместимой лицензией, авторское свидетельство. А откуда технологии — дело не первой важности. Можно подумать ядро линукса разрабатывается у нас.
Еще из примеров: не так давно описывали на хабре свой случай с видеорекламой 2ГИС. Так что это востребовано.
AxisPodhVosttunsafePtr использование исключений — это одна из многих холиварных тем. например, никого не смущают ArgumentNullException или InvalidArgumentException и тп. исключения — это инструмент по управлению поведением приложения отличного от валидного/основного. если брать rest, при тех же ошибках в запросе обычно возвращается не 200 и {IsError=true}, а 4хх. исключения удобны, когда разные проверки скрыты в слоях сервисов и вызовов, чтобы каждый метод не анализировал результат выполнения вложенного, если и так понятно, что продолжать дальше нельзя. бросил свой тип исключения, в обработчике, например, глобальном поймал, залогировал и вернул соответствующий response клиенту. все ходы записаны ошибки анализируются и логируются в одном месте довольно компактным кодом, откуда бы они не прилетели; отдаются в том формате, в котором клиент это поймет. лепота. и, касательно валидации входных парамеров, ActionFilter выглядит лучше, чем ThrowIfModelIsInvalid. имхо.
Выход: не прокидывать сущности наружу.
У нас слой сервисов (не путать с веб-сервисами) никаких сущностей даже между собой(сервис-сервис) не передает, не говоря уже о выкидывании наружу — только маппинг во входные/выходные типы, либо передача идентификаторов. Как правило, контекст базы инжектируется общий на скоуп, поэтому проблем здесь нет.
У нас не настолько нагруженный проект был, и его нужно было мигрировать. Да и я б еще подумал брать ли вообще EF в нагруженный проект. Суть не в том, что у нас ленивые жопки, не знающие про n+1, а в том, что это удобнее, чем делать отдельно .Load(), и лучше eager loading данных, которые могут не понадобиться. Кто-то этим пользуется, кто-то нет. Заменить один случай lazy loading — не проблема вообще, но миграция проекта — это довольно кропотливая работа, нужно было пересмотреть много мест по коду.
Фича Lazy loading — холиварная тема. Вот там тонны добра с обеих сторон, отметились даже некоторые известные люди github.com/aspnet/EntityFrameworkCore/issues/3797
В освновном из-за конфигурации и некоторых возможностей, а также лимита времени(и немного лени). Конфигурация DI переехала вообще без изменений. В проекте не использовался скан сборок с автоматической конфигурацией. Был сайт, фоновый сервис и несколько сервисных утилит. В каждой программе свой набор компонент и свой конфиг.
У нас часто используется Lazy<>, чтобы вещи, которые не всегда используются в сервисе, не создавались каждый раз. Насколько я помню, в дефолтном контейнере забраковали open generics. К тому же есть пара мест с child контейнерами (этой фичи тоже нет стандартном). Еще было бы лениво заменять в конструкторах ILogger на ILogger, у нас уже был модуль для autofac, который делал черную магию, зная о типе, куда будет инжектироваться параметр.
Был angularjs/webapi2/signalr + workerservice проект с EF 6 на postgresql, который надо было перетянуть под linux.
Из граблей в основном грабли от ms, сторонние либы на удивление быстро и без особого изменения поведения/конфигурации перескочили (autofac, automapper, hangfire, npgsql и тд):
1) EF 6 -> EF Core 2.0: нет groupby (уже в гите); нет lazy loading(больше года делают и в лучшем случае в начале 2018); с хранимками и маппингом функций бывают траблы; многие ко многим только через промежуточную сущность(но обещают сделать как и былО).
2) Ldap: Не из коробки. два года обсуждали, сделали пока только под винду github.com/dotnet/corefx/issues/2089, но есть различные форки новеловской либы.
3) WebApi 2 -> aspnet core 2: Были забавные случаи с байндингом, где не стоял явный [FromBody]: приходили объекты с пустыми полями, документация по переезду про это мало знает, люди мутят гибридные байндеры. Пришлось подразбираться с конфигурацией приложения при запуске, с конфигурацией (ConfigurationManager появился только с этим пакетом), контейнеров, воткнуться в пайп(чтобы ловить исключения).
4) Signalr: относительно недавно появился preview. Немного доделок и все заработало.
5) Были грабли с определением рабочего каталога при запуске с отладкой и без (фикс только сегодня за пулреквестили)
6) решарпер со студией пару раз зареференсили либу вместо nuget пакета, нужно следить.
7) отказались от tika.net потому, что автор ikvm.net забил весной на проект и переезда не будет.
Я прям представляю, как приходит к нам сеньор, который последние 5 лет пилил документооборот, а у нас шоп платформа с 150+ интеграциями. И мы ему такие, к примеру, а нам надо прикрутить серверный фейсбук пиксель с LDU CCPA и всеми нужными событиями и данными, ну и морду в админку к этому всему. И он такой, "ок, ща почитаю википедию, завтра можно будет что-то посмотреть". Он только в том, как проект устроен, будет разбираться недели полторы. И окружение для разработки настраивать полдня минимум.
А в стартапах порой так чудно все устроено, agile завязанный узлом порой творит чудеса, которые выливаются в "офигительные технические решения", "исторически так сложилось" или "зачем здесь это? и зачем это? а это?! ... ах, вот зачем..".
Друго дело, конечно, если ему дали простую отдельностоящую задачку в духе сделай crud для вот этой фигни и он делал её две недели.
По базам: postgresql там из коробки даже в special edition (хотя не самый новый), кому не нравится, есть postgrespro с плюшками и сертификатом. Работает с EntityFramework.
Требования на разработку включают исходники на все ПО с совместимой лицензией, авторское свидетельство. А откуда технологии — дело не первой важности. Можно подумать ядро линукса разрабатывается у нас.
Еще из примеров: не так давно описывали на хабре свой случай с видеорекламой 2ГИС. Так что это востребовано.
Добавить в атрибут параметр — метод, заполняющий модель для вьюхи?
ходы записаныошибки анализируются и логируются в одном месте довольно компактным кодом, откуда бы они не прилетели; отдаются в том формате, в котором клиент это поймет. лепота. и, касательно валидации входных парамеров, ActionFilter выглядит лучше, чем ThrowIfModelIsInvalid. имхо.У нас слой сервисов (не путать с веб-сервисами) никаких сущностей даже между собой(сервис-сервис) не передает, не говоря уже о выкидывании наружу — только маппинг во входные/выходные типы, либо передача идентификаторов. Как правило, контекст базы инжектируется общий на скоуп, поэтому проблем здесь нет.
Фича Lazy loading — холиварная тема. Вот там тонны добра с обеих сторон, отметились даже некоторые известные люди github.com/aspnet/EntityFrameworkCore/issues/3797
И бонусом про Lazy github.com/aspnet/DependencyInjection/issues/98
немного лени). Конфигурация DI переехала вообще без изменений. В проекте не использовался скан сборок с автоматической конфигурацией. Был сайт, фоновый сервис и несколько сервисных утилит. В каждой программе свой набор компонент и свой конфиг.У нас часто используется Lazy<>, чтобы вещи, которые не всегда используются в сервисе, не создавались каждый раз. Насколько я помню, в дефолтном контейнере забраковали open generics. К тому же есть пара мест с child контейнерами (этой фичи тоже нет стандартном). Еще было бы лениво заменять в конструкторах ILogger на ILogger, у нас уже был модуль для autofac, который делал черную магию, зная о типе, куда будет инжектироваться параметр.
Из граблей в основном грабли от ms, сторонние либы на удивление быстро и без особого изменения поведения/конфигурации перескочили (autofac, automapper, hangfire, npgsql и тд):
1) EF 6 -> EF Core 2.0: нет groupby (уже в гите); нет lazy loading(больше года делают и в лучшем случае в начале 2018); с хранимками и маппингом функций бывают траблы; многие ко многим только через промежуточную сущность(но обещают сделать как и былО).
2) Ldap: Не из коробки. два года обсуждали, сделали пока только под винду github.com/dotnet/corefx/issues/2089, но есть различные форки новеловской либы.
3) WebApi 2 -> aspnet core 2: Были забавные случаи с байндингом, где не стоял явный [FromBody]: приходили объекты с пустыми полями, документация по переезду про это мало знает, люди мутят гибридные байндеры. Пришлось подразбираться с конфигурацией приложения при запуске, с конфигурацией (ConfigurationManager появился только с этим пакетом), контейнеров, воткнуться в пайп(чтобы ловить исключения).
4) Signalr: относительно недавно появился preview. Немного доделок и все заработало.
5) Были грабли с определением рабочего каталога при запуске с отладкой и без (фикс только сегодня за пулреквестили)
6) решарпер со студией пару раз зареференсили либу вместо nuget пакета, нужно следить.
7) отказались от tika.net потому, что автор ikvm.net забил весной на проект и переезда не будет.
Итого: самая большая боль — EF Core