Comments 68
Про десктоп, проект AvaloniaUI. Базируется на XAML. Ну ещё и не релиз пока, но можно уже много интересного делать.
О, расскажи про Авалонию. Ты уже что-нибудь пробовал сделать? Что показалось наиболе интересным, чудесным и вообще труЪшным? Какие грабли собрал?
Зовите kekekeks, он расскажет)
А что рассказывать, на дотнексте я уже по этому поводу вещал. Ждите релиза беты в начале года.
Мы перепрыгнули уже довольно давно, полет нормальный. Кластер из нескольких Коровских нод на Никсах за Хапрокси и последовательный деплой без даунтайма — берем лучшее из обоих миров.
Можете немного подробнее рассказать как все работает? Хотим у себя сделать нечто подобное, но пока только в начале пути. Например, чем деплой делаете?
Ansible. Но это не принципиально. Можно шелл-скриптом из репозитория раскатывать, если нод немного. Деплой в новую папку, стоп старой, старт новой версии. Откат еще быстрее. Если ХА не нужен, можно оставить Кастрюлю, смотрящей в сеть, как есть. Делали нагрузочные на Никсах, она параллельно летает. Асинк-авейт, все такое. Нгинкс как прокси перед Кастрюлей показался избыточным. Но то дело вкуса.
Непонятно. System.Data.SqlClient доступен был с незапамятных времен, отдельным пакетом. Если Microsoft.Windows.Compatibility можно ставить по частям, то так и надо написать.
Не только «десктопные приложения» неподдерживаются…
System.Diagnostics.PerformanceCounter и System.DirectoryServices только только стали доступны как preview1 (в вашей таблице Coming это и означает). т.е. портировать серверный код (где без данных библиотек не обходится) — удел одиночек. Писать новые проекты — конечно надо под core, осваивая новую МС телеметрию и вынося адапетр к ActiveDirectory в отдельный удаленный сервис, который будет крутится под Classic .NET Framework.
System.Diagnostics.PerformanceCounter и System.DirectoryServices только только стали доступны как preview1 (в вашей таблице Coming это и означает). т.е. портировать серверный код (где без данных библиотек не обходится) — удел одиночек. Писать новые проекты — конечно надо под core, осваивая новую МС телеметрию и вынося адапетр к ActiveDirectory в отдельный удаленный сервис, который будет крутится под Classic .NET Framework.
Ну тут такое, release early, release often, как говорил батюшка наш Эрик Реймонд. Наверное, раз уж подписался на участие опенсорце, придется жить по опенсорцным заповедям: постоянно сидеть на превьюхах, мониторить новости, адоптить частые апдейты. И главное, справляться своими силами, а не ждать, пока добрый дяденька из Microsoft тебе всё запилит.
К сожалению, сейчас .NET Core не покрывает нужды десктопной разработки. Возможно, когда-нибудь это изменится. Но это уже совсем другая история.
.NET Core, как и старший .NET Framework, умеет в DllImport, маршалинг между managed и unmanaged. Т.е. платформа как исполнитель управляемого кода и интегратор с неуправляемым ОС-специфичным кодом как раз все позволяет и покрывает. Поэтому правильнее говорить, что нынешний набор пакетов не покрывает все нужды десктопной разработки.
Всё равно осадочек остался от того что протащили windows-only API. Лучше совсем без них, и для windows-a предоставлять их в виде отдельных nuget пакетов. В принципе это ещё не поздно исправить, но никто этим заниматься не будет. Сейчас у них цель, проапгредить и заоптимизировать сетевой стек.
Настало время перетащить ее на правоверный Linux, работающий на Azure!
Один я вижу в этих словах противоречие? =)
А зачем мы давно хотим перелезть на .NET Core?
UFO just landed and posted this here
Стильно, модно, молодежно :)
Есть клиенты, которые не хотят сервера на Windows, но им подходит некое ПО на ASP.NET.
Переводим ПО на .NET Core, добиваемся устойчивой работы в Linux, продаём, profit.
Ясно.
Они просто не умеют их поддерживать — просто продайте им ещё и саппорт для Windows серверов :)
profit x 2
Они просто не умеют их поддерживать — просто продайте им ещё и саппорт для Windows серверов :)
profit x 2
Дело не в этом. Есть такое слово "импортозамещение". И оно уже давно является драйвером изменений в IT, причем не только в госсекторе.
А у вас СУБД «правильная»?
И только не говорите заказчику, что вы используете технологии Microsoft.
В «не только в госсекторе» мне кажется импортозамещение началось уже сразу с появлением этого «не только в госсекторе» :)
И только не говорите заказчику, что вы используете технологии Microsoft.
В «не только в госсекторе» мне кажется импортозамещение началось уже сразу с появлением этого «не только в госсекторе» :)
По СУБД тоже есть хорошие новости:
https://www.microsoft.com/ru-ru/sql-server/sql-server-2017
Я не о том, вы бы ещё клиентам предложили Windows Server в виртуализации Linux запустить, если они сервера на Windows не хотят. Вы им тогда и лицензии на vmware продадите, и саппорт виртуализации, и саппорт на Windows сервер в виртуализации… уже я даже сбился со счёт на сколько надо profit множать в таком случае.
Это всю шутки конечно, но с долей правды.
И всё же «масло масляное» — от Microsoft вы так заказчиков не сбережете, «они» всёравно будут руководить вами :)
Microsoft всегда имел хороший маркетинг для программистов и это вот «ВСЁ» с open source и linux на фоне прошлых «неудачных» и выгодных для Microsoft технологий, должно насторожить тревожного разработчика.
Это всю шутки конечно, но с долей правды.
И всё же «масло масляное» — от Microsoft вы так заказчиков не сбережете, «они» всёравно будут руководить вами :)
Microsoft всегда имел хороший маркетинг для программистов и это вот «ВСЁ» с open source и linux на фоне прошлых «неудачных» и выгодных для Microsoft технологий, должно насторожить тревожного разработчика.
Можно просто посчитать на сколько денег продали астралинукса и других отечественных линуксов за последний год для гос и около контор. И их реально сейчас пытаются активно внедрять. Возникла потребность в ПО для линуксов. У многих уже были свои работающие решения на dotnet на винде, кто-то решил заказать замену своим еще dos программам. Выход dotnet core 2 сильно помог компаниям, не меняя программистов и не переписывая весь код, постараться вписаться в этот праздник импортозамещения.
По базам: postgresql там из коробки даже в special edition (хотя не самый новый), кому не нравится, есть postgrespro с плюшками и сертификатом. Работает с EntityFramework.
Требования на разработку включают исходники на все ПО с совместимой лицензией, авторское свидетельство. А откуда технологии — дело не первой важности. Можно подумать ядро линукса разрабатывается у нас.
Еще из примеров: не так давно описывали на хабре свой случай с видеорекламой 2ГИС. Так что это востребовано.
По базам: postgresql там из коробки даже в special edition (хотя не самый новый), кому не нравится, есть postgrespro с плюшками и сертификатом. Работает с EntityFramework.
Требования на разработку включают исходники на все ПО с совместимой лицензией, авторское свидетельство. А откуда технологии — дело не первой важности. Можно подумать ядро линукса разрабатывается у нас.
Еще из примеров: не так давно описывали на хабре свой случай с видеорекламой 2ГИС. Так что это востребовано.
Надо было сразу на PHP, Java или Go писать что бы потом не ползать по .net core-ам.
Да и зачем всё переписывать если есть виртуальные машины с образами систем готовых систем, которые разворачиваются по мере необходимости. И так работает зачем еще переплачивать?
Да и зачем всё переписывать если есть виртуальные машины с образами систем готовых систем, которые разворачиваются по мере необходимости. И так работает зачем еще переплачивать?
И так работает зачем еще переплачивать?
Как я понял, в статье речь о том, что это стало практически бесплатно. Без виртуальных машин и прочего инструментального оверинжиниринга.
Посмотрите на современный софт, оверинжиниринг никого не пугает. Да же наоборот, притягивает. Контейнеры, виртуальные машины, облака. Зачем переписывать побольше инстансов оплатил и вперёд. Труд программистов дорог, а вычислительных мощностей хоть ж… ой ещь и не дорого.
В современности много бестолковых специалистов, которые готовы технологиями (и ресурсами для них) покрывать свою безграмотность. Безусловно, их такие возможности радуют.
Виртуализация — отличная вещь там, где она нужна. В любую дырку толкать докер лишь потому, что это мейнстримово — это очевидная глупость, за которую платит бизнес.
Виртуализация — отличная вещь там, где она нужна. В любую дырку толкать докер лишь потому, что это мейнстримово — это очевидная глупость, за которую платит бизнес.
Зачем переписыватьНе нужно ничего переписывать, о том и статья.
UFO just landed and posted this here
Странно, а в заголовке «переписывать».Забавно, но в тексте статьи этого нет. Все эпитеты про «перетащить» подразумевают запуск в новом окружении. Пакет призван обеспечить слой совместимости на уровне исходников.
И по факту, чтобы приложение было .NET, а стало Core — его придётся переписывать.Это совсем не факт, ибо сильно зависит от самого приложения и состояния сабжект-пакета.
Если кто-то питает иллюзии, что ничего не придется переписывать — стоит перестать это делать.
Из того, на что напарывались:
— Nhibernate -> Dapper
— Ninject -> стандартный DI
— log4net заводится через одно место
— полностью новая инициализация сервиса(на Net 4.6 был OWIN + Topshelf)
— завести NUnit на TeamCity нифига не просто и тащит за собой обновление TeamCity
— переписать билд-скрипты на dotnet build|publish
Из того, на что напарывались:
— Nhibernate -> Dapper
— Ninject -> стандартный DI
— log4net заводится через одно место
— полностью новая инициализация сервиса(на Net 4.6 был OWIN + Topshelf)
— завести NUnit на TeamCity нифига не просто и тащит за собой обновление TeamCity
— переписать билд-скрипты на dotnet build|publish
Почти все что вы перечислили можно описать одним словом: сторонние библиотеки/продукты.
Да, если сторонний продукт который вы используете не поддерживает Core — вы не сможете без переписывания работающего с ним кода переехать на Core. Это очевидно же…
PS так вернули же msbuild в core, разве нет?
Да, если сторонний продукт который вы используете не поддерживает Core — вы не сможете без переписывания работающего с ним кода переехать на Core. Это очевидно же…
PS так вернули же msbuild в core, разве нет?
Ninject -> стандартный DIАктуальный (стабильный) Ninject умеет в .NET Standard 2.0
— Nhibernate -> Dapper
— Ninject -> стандартный DI
— log4net заводится через одно место
— полностью новая инициализация сервиса(на Net 4.6 был OWIN + Topshelf)
— завести NUnit на TeamCity нифига не просто и тащит за собой обновление TeamCity
— переписать билд-скрипты на dotnet build|publish
1. Nhibernate имеет единственную зависимость Iesi.Collections, которые уже перетащены на кор.
2. Поддерживает кор
3. Но заводится же. При этом это код, который пишется единожды. Плюс сам выбор инструмента тоже влияет, у нас например используется ELK и мы ничего не переписывали.
4. Тут да, надо переписать, но нужно понимать, что Topshelf зависит от Windows service инфраструктуры, которой непонятно откуда взяться на кроссплатформенном окружении. Хотя в 2.1 вроде должны каким-то образом исхитриться. Видимо так же, как эмуляция реестра файлами на линуксе, которую они делали.
5. Обновление TeamCity тоже делается единожды, причем практически без затрат.
6. 30 минут работы девопса.
В итоге большинство претензий либо уже не актуальны, либо сводятся к «один раз поправить билдстепы». Единственная, с которой могу согласиться — Topshelf, но не у всех такие требования, запускать кроссплатформенный сервис.
Плюсов для меня лично больше. Самый большой — возможность переключатся между ветками в гите без перезагрузки всего солюшена + удобство в потреблении и создании нугет пакетов.
А вот опыт товарища focuspocus показателен, там мне нечего сказать, кроме как «сочувствую» :)
Для нас плюсов тоже было больше, чем минусов — иначе бы не переводили.
Пост был не про то, что нельзя перехать, а про то, что даже на средних размеров проекте это вполне себе ощутимые трудозатраты(ну или мы что-то не так делали). Данный момент, как минимум, стоит держать в голове.
Также раз уж написал про проблемы, то напишу и про маленькие приятности, помимо кросплатформенности, которые дает net core:
— удобный механизм переопределения appsettings.json(в прошлом app.config) из коробки: можно таскать переопределения ключей из консоли, файлов, перменных окружения
— csproj файлы стали намного более читаемые и удобные. теперь на них можно смотреть(и мерджить) без боли
— более удобное подключение нугет пакетов: ссылка на пакет добавляется в csproj и все. без всяких там UI и сгенерированных hintPath, как это было в старом csproj.
— стандратный DI вполне адекватен и вообщем-то что-то стороннее ставить не всегда есть смысл
Пост был не про то, что нельзя перехать, а про то, что даже на средних размеров проекте это вполне себе ощутимые трудозатраты(ну или мы что-то не так делали). Данный момент, как минимум, стоит держать в голове.
Также раз уж написал про проблемы, то напишу и про маленькие приятности, помимо кросплатформенности, которые дает net core:
— удобный механизм переопределения appsettings.json(в прошлом app.config) из коробки: можно таскать переопределения ключей из консоли, файлов, перменных окружения
— csproj файлы стали намного более читаемые и удобные. теперь на них можно смотреть(и мерджить) без боли
— более удобное подключение нугет пакетов: ссылка на пакет добавляется в csproj и все. без всяких там UI и сгенерированных hintPath, как это было в старом csproj.
— стандратный DI вполне адекватен и вообщем-то что-то стороннее ставить не всегда есть смысл
Может быть стоит наиболее общие части кода выносить в рамки .Net Standart?
Стоит упомянуть, что из проектов на .NET Core 2.0+ можно референсить сборки и нугеты ЛЮБОЙ версии .NET, и оно будет работать под линух, если либа не использует windows-specific API.
То есть если вы — автор библиотеки, то не обязательно переезжать на кору, достаточно проверить, что нет windows-specific вызовов, или обернуть их в if-else.
Мы так поступили в Apache Ignite.NET. Всё работает под линух и макось, но сохранена поддержка VS 2010.
К чему Microsoft идет в итоге?
Делает Кросс-платформенный фреймворк + отдельно фреймворк для винды. Или все же сделает один адекватный фреймворк подо все + отдельный пакет для лучшей интеграции с виндой?
Делает Кросс-платформенный фреймворк + отдельно фреймворк для винды. Или все же сделает один адекватный фреймворк подо все + отдельный пакет для лучшей интеграции с виндой?
Сделать кросс платформенный NET Core это реально хорошая идея и в какой-то степени может потеснить Java на nix платформе.
1) Сделать полную поддержку на Linux — тогда Java подвинется, так как зачастую именно цена хостинга + лицензий (отпугивает стартапы) + отсутствие тулзов линукса отпугивает крупные проекты.
2) Сделать Gui-инструмент для Linux/MAC — тогда уже подвинутся все остальные.
2) Сделать Gui-инструмент для Linux/MAC — тогда уже подвинутся все остальные.
Радуюсь появлению .net core, все свои пет проекты пишу на нем, под VS 2017 и Win10, а запускаю их на simplecloud на 150р тарифе под Ubuntu.
Мне как раз подходит на 100%.
Мне как раз подходит на 100%.
1) Сделать полную поддержку на Linux — тогда Java подвинется, так как зачастую именно цена хостинга + лицензий (отпугивает стартапы) + отсутствие тулзов линукса отпугивает крупные проекты.
Так или иначе движ есть. MS раньше позиционировалась как вещь в себе, типа нафиг эти ваши линуксы, у нас есть все(сервер, базы, серверные приложения) и мы крутые. Но мир поменялся, линукс плотно осел на сервер сайде и MS долю серверного рынка на Linux полностью потеряла. Потом они начали пытаться «запрыгнуть в уходящий вагон» и начали накручивать всякую совместимость(она правда и до этого была, но кто ей пользовался хз) с Linux, en.wikipedia.org/wiki/Windows_Subsystem_for_Linux.
Про последнее я тоже не думаю что это прям взлетит. Общие кейсы в голову не приходят, а какие-то узкоспециализированные интереса не представляют.
А вот .NET это несколько другое общий и обширный вариант использования это ASP.NET да и да и просто серверные .NET приложения. И вот с этим крюком MS может залезть в Linux вагон.
Это не говорит о том, что все ринутся переписывать. Но при выборе платформы для нового приложения решение может склониться в сторону .NET on Linux
я извиняюсь, но имело смысл указать, что это перевод поста Иммо — blogs.msdn.microsoft.com/dotnet/2017/11/16/announcing-the-windows-compatibility-pack-for-net-core
Ссылка же на оригинал новости есть прямо в первом абзаце (и она была там всегда, до этого комментария).
Но это не перевод, а рерайт. Несмотря на в общем похожую структуру, есть важная разница в ряде моментов: например, я утверждаю что на .Net Core переходить нужно в любом случае просто потому что это Free Software, и мне как FS/OSS-человеку это самое важное. Я супер редко пользуюсь какими-либо продуктами Microsoft именно потому, что это не Free Software, неважно насколько качественными или полезными они при этом являются. Но это совершенно не годится на официальную позицию Microsoft.
На «официальную позицию» не годится так же идея о том, что текущий подход к портированию — неудобный, и людям которые хотят что-то портировать — им остается только страдать. На официальную позицию не тянет троекратное упоминания подозрения, что половина читающих эту статью — те еще быдлокодеры и копипастеры со StackOverflow.
В принципе, мне ставить галочку «перевод» даже выгодно. Но вряд ли Microsoft обрадывалось бы двачерским словечкам и оборотам, которые приписали бы им словом «перевод» в заголовке. Это важный для меня момент, т.к. я не собираюсь ни отказываться от двачерской лексики, ни от глумёжа и обвинений в быдлокодерстве, итп — это мой стиль. Но при этом не хочу иметь официальные конфликты с Microsoft.
Я думаю, так или иначе, большинство новостей в мире фреймворков вторичны, и новости будут так или иначе идти от корневых источников — мейлинг-листов и сайтов авторов. Так что в дальнейшем рерайты новостей я писать продолжу. Вряд ли стоит выражать вторичность новости в виде галки «перевод».
Какие выводы я сделал из вашего комментария: в будущем нужно будет делать более глубокую проработку новости и менять её структуру, чтобы она не была «переводом» на уровне структурных блоков (или хотя бы — порядка структурных блоков).
Но это не перевод, а рерайт. Несмотря на в общем похожую структуру, есть важная разница в ряде моментов: например, я утверждаю что на .Net Core переходить нужно в любом случае просто потому что это Free Software, и мне как FS/OSS-человеку это самое важное. Я супер редко пользуюсь какими-либо продуктами Microsoft именно потому, что это не Free Software, неважно насколько качественными или полезными они при этом являются. Но это совершенно не годится на официальную позицию Microsoft.
На «официальную позицию» не годится так же идея о том, что текущий подход к портированию — неудобный, и людям которые хотят что-то портировать — им остается только страдать. На официальную позицию не тянет троекратное упоминания подозрения, что половина читающих эту статью — те еще быдлокодеры и копипастеры со StackOverflow.
В принципе, мне ставить галочку «перевод» даже выгодно. Но вряд ли Microsoft обрадывалось бы двачерским словечкам и оборотам, которые приписали бы им словом «перевод» в заголовке. Это важный для меня момент, т.к. я не собираюсь ни отказываться от двачерской лексики, ни от глумёжа и обвинений в быдлокодерстве, итп — это мой стиль. Но при этом не хочу иметь официальные конфликты с Microsoft.
Я думаю, так или иначе, большинство новостей в мире фреймворков вторичны, и новости будут так или иначе идти от корневых источников — мейлинг-листов и сайтов авторов. Так что в дальнейшем рерайты новостей я писать продолжу. Вряд ли стоит выражать вторичность новости в виде галки «перевод».
Какие выводы я сделал из вашего комментария: в будущем нужно будет делать более глубокую проработку новости и менять её структуру, чтобы она не была «переводом» на уровне структурных блоков (или хотя бы — порядка структурных блоков).
Переезжать серверным системам стоит если:
а) вы видите профит от снижения затрат на хостинг за счет перехода на линукс
б) у вас (микро)сервисы и вы понимаете зачем вам докер
в) ваш заказчик купил линукс сервера, не посоветовашись с вами
Новые проекты имхо стоит все-таки начинать сразу под netstandard2.0 или вообще на java от греха подальше=)
а) вы видите профит от снижения затрат на хостинг за счет перехода на линукс
б) у вас (микро)сервисы и вы понимаете зачем вам докер
в) ваш заказчик купил линукс сервера, не посоветовашись с вами
Новые проекты имхо стоит все-таки начинать сразу под netstandard2.0 или вообще на java от греха подальше=)
Был 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 забил весной на проект и переезда не будет.
Итого: самая большая боль — EF Core
Из граблей в основном грабли от 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
Вопрос в сторону, поделитесь опытом, а почему вы предпочли оставить autofac когда в Core DI из коробки (который я не использую, правда я ни один стандартный IoC container не использую поскольку мне нужна поддержка экземпляров «per session» и решается это как раз отказом от IoC container'ов и ручным DI)?
В освновном из-за конфигурации и некоторых возможностей, а также лимита времени(и немного лени). Конфигурация DI переехала вообще без изменений. В проекте не использовался скан сборок с автоматической конфигурацией. Был сайт, фоновый сервис и несколько сервисных утилит. В каждой программе свой набор компонент и свой конфиг.
У нас часто используется Lazy<>, чтобы вещи, которые не всегда используются в сервисе, не создавались каждый раз. Насколько я помню, в дефолтном контейнере забраковали open generics. К тому же есть пара мест с child контейнерами (этой фичи тоже нет стандартном). Еще было бы лениво заменять в конструкторах ILogger на ILogger, у нас уже был модуль для autofac, который делал черную магию, зная о типе, куда будет инжектироваться параметр.
У нас часто используется Lazy<>, чтобы вещи, которые не всегда используются в сервисе, не создавались каждый раз. Насколько я помню, в дефолтном контейнере забраковали open generics. К тому же есть пара мест с child контейнерами (этой фичи тоже нет стандартном). Еще было бы лениво заменять в конструкторах ILogger на ILogger, у нас уже был модуль для autofac, который делал черную магию, зная о типе, куда будет инжектироваться параметр.
Извиняюсь! Перечитал уже после отправки. Выпало важное слово! «забраковали constrained open generics». Даже нашел подробности github.com/aspnet/DependencyInjection/issues/471
И бонусом про Lazy github.com/aspnet/DependencyInjection/issues/98
И бонусом про Lazy github.com/aspnet/DependencyInjection/issues/98
Ну, lazy loading больше для прототипов же фича, в нагруженном же проекте lazy loading является лучшим способом убиения производительности…
У нас не настолько нагруженный проект был, и его нужно было мигрировать. Да и я б еще подумал брать ли вообще EF в нагруженный проект. Суть не в том, что у нас ленивые жопки, не знающие про n+1, а в том, что это удобнее, чем делать отдельно .Load(), и лучше eager loading данных, которые могут не понадобиться. Кто-то этим пользуется, кто-то нет. Заменить один случай lazy loading — не проблема вообще, но миграция проекта — это довольно кропотливая работа, нужно было пересмотреть много мест по коду.
Фича Lazy loading — холиварная тема. Вот там тонны добра с обеих сторон, отметились даже некоторые известные люди github.com/aspnet/EntityFrameworkCore/issues/3797
Фича Lazy loading — холиварная тема. Вот там тонны добра с обеих сторон, отметились даже некоторые известные люди github.com/aspnet/EntityFrameworkCore/issues/3797
Lazy loading плохо выглядит архитектурно: заполненность свойства оказывается зависима от того, был ли освобожден контекст и было ли ранее чтение из этого свойства пока не был освобожден контекст. Куча неявного состояния. Как результат — полагающийся на LL код получается хрупким и может перестать работать из-за изменений в совершенно другом куске кода.
Если уж действительно важно загружать данные по требованию — лучше использовать Explicit loading, передавая контекст вместе с сущностью. Необходимость передачи контекста в метод исключает ситуацию когда контекст освободили а потом пытаемся сделать запрос.
Если уж действительно важно загружать данные по требованию — лучше использовать Explicit loading, передавая контекст вместе с сущностью. Необходимость передачи контекста в метод исключает ситуацию когда контекст освободили а потом пытаемся сделать запрос.
Выход: не прокидывать сущности наружу.
У нас слой сервисов (не путать с веб-сервисами) никаких сущностей даже между собой(сервис-сервис) не передает, не говоря уже о выкидывании наружу — только маппинг во входные/выходные типы, либо передача идентификаторов. Как правило, контекст базы инжектируется общий на скоуп, поэтому проблем здесь нет.
У нас слой сервисов (не путать с веб-сервисами) никаких сущностей даже между собой(сервис-сервис) не передает, не говоря уже о выкидывании наружу — только маппинг во входные/выходные типы, либо передача идентификаторов. Как правило, контекст базы инжектируется общий на скоуп, поэтому проблем здесь нет.
Sign up to leave a comment.
ААА! Пришло время переписывать на .NET Coreǃ