Комментарии 9
была возможность использовать бекграунд воркера (то есть второй процесс, запущенный в параллель, в котором выполнялись работы)
Простите, а это точно соответствует истине? Даже гуглить пошёл — вдруг я 13 лет в неведении пребываю.
Подозреваю неточную терминологию.
BackgroundWorker Class
.NET Framework
4.8 4.7.2 4.7.1 4.7 4.6.2 4.6.1 4.6 4.5.2 4.5.1 4.5 4.0 3.5 3.0 2.0
.NET Framework
4.8 4.7.2 4.7.1 4.7 4.6.2 4.6.1 4.6 4.5.2 4.5.1 4.5 4.0 3.5 3.0 2.0
Я помню я начинал в 2005 с .Net 1.1
Это была достаточно серьезная боль, которая закончилась с появлением версии фреймворка 3.0 (третья революция в .Net, как я считаю… Где первая — это сам .Net, вторая — это ThreadPool+AsyncProgrammingModel+Generics версии 2.0, а четвертая — .Net core).
Но даже тогда асинхроность была ибо это принцип многозадачности операционных систем.
Поэтому не могу разделить патетики.
Писать на Линукс — основная ли это цель платформы? Не уверен.
Но то что .Net core решила проблему многоплатформенности — это факт.
Но… это практически и все «обезболивающее» :)
P.S. оптимизация garbage collector и оптимизация ресурсов (используемой памяти и быстродействия) с .Net Core имеет слабую связь. Основное было сделано, по-моему, или в 4.6.2 или в 4.7 .Net Framework
Это была достаточно серьезная боль, которая закончилась с появлением версии фреймворка 3.0 (третья революция в .Net, как я считаю… Где первая — это сам .Net, вторая — это ThreadPool+AsyncProgrammingModel+Generics версии 2.0, а четвертая — .Net core).
Но даже тогда асинхроность была ибо это принцип многозадачности операционных систем.
Поэтому не могу разделить патетики.
Писать на Линукс — основная ли это цель платформы? Не уверен.
Но то что .Net core решила проблему многоплатформенности — это факт.
Но… это практически и все «обезболивающее» :)
P.S. оптимизация garbage collector и оптимизация ресурсов (используемой памяти и быстродействия) с .Net Core имеет слабую связь. Основное было сделано, по-моему, или в 4.6.2 или в 4.7 .Net Framework
.Net Core с его возможностью компиляции в нативный исполняемый код решает одну из основных проблем — вы перестаёте распространять свои приложения (практически) в исходниках. Правда, компиляция в нативный код — те ещё танцы. У меня пока двоякое чувство от Core — вроде бы то, чего давно ждали, но есть и ощущение недоделанности…
«Недоделанность» присутствует это факт, ибо есть вещи, которые в Core и в Framework, работают по разному. По началу было сложно с Ef, но потом втянулся:-) и ещё остаются вещи которые ещё не переписаны к сожалению, но уже есть так-же механизмы которые есть только в Core. И все новое что появляется в Framework идёт из Core.
Как по мне так создание Roslyn-a было революцией. До этого разработчики языка что бы делать язык использовали С++. .netcore это как раз плоды рослина
SqlDataSource
Со времён 1.1, использование SqlDataSource и ObjectDataSource встречал только в мануаулах на сайтах M$, на практике их никто не использовал, ибо мешать слои UI и доступа к данным, даже тогда считалось плохой практикой. Моё предположение, что использование этих объектов в примерах, обуславливалось уменьшением текста для новичков: CC->CV->F5
В .NET Framework 3.5 не было асинхронности ¬¬в том виде, котором мы знаем её сейчас
Да, обёртку приходилось писать самостоятельно на основе ThreadPool'ов…
Что в 4.0 из коробки сделали в TPL.
Также в .NET Framework 3.5 появилась еще одна болезненная технология — MS AJAX
M$ AJAX появился в 2.0, а не в 3.5. Тут даже за пруфами далеко ходить не надо:
System requirements: Microsoft .NET Framework Version 2.0
А использовать в той версии «шарика» классический AJAX (XMLHttpRequest) не представлялось возможным
В обычных вебформах было несколько сценариев, от накручивания WebMethodAttribute, до IHttpHandler.
Ну а далее — любые другие приложения на любых языках, способные обработать JSON.
PS: С SP не работал.
Эх, молодёжь… В 3.5 им много чего не хватало. Вот когда попробовали бы 1.1, где даже generic-ов не было и все писали свои обёртки над ArrayList…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вечное сияние чистого .NET